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The  DoD  test  range  community  has  come  to  the  realization  that  its  telemetry  abilities  are  obsolete.  Efforts 
are  therefore  underway  to  improve  telemetry  systems  at  DoD  test  ranges.  The  overall  objective  of  this 
project  was  to  evaluate  the  practical  use  of  the  CCSDS  packet  telemetry  protocol  in  DoD  test  ranges  and 
determine  the  configuration  that  would  maximize  performance  based  on  mission  requirements.  A 
secondary  objective  was  to  compare  the  CCSDS  and  ATM  protocols  in  order  to  substantiate  further 
exploration  of  using  ATM  in  future  DoD  telemetry  systems.  Modeling  and  simulation  of  the  CCSDS 
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quality  performance.  Flight  tests  confirmed  the  correlation  between  the  CCSDS  parameters  and  the 
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results  matched  those  of  the  modeling  and  simulation  work.  Data  collected  also  indicated  that 
performance  of  the  ATM  protocol  is  sufficiently  close  to  that  of  CCSDS  to  warrant  further  investigation 
of  using  ATM  on  test  ranges.  ATM  offers  the  military  user  straightforward  interoperability  with  civilian 
systems/networks. 
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Abstract 

The  DoD  range  community  has  recognized  that  its  Telemetry  (TM)  link  abilities 
are  quickly  becoming  obsolete.  To  date,  the  40- year-old  technology  used  in  its  telemetry 
systems  has  sufficed  for  DoD  test  ranges.  However,  with  increasingly  advanced  weapons 
systems  coming  on-line,  this  "old"  technology  is  no  longer  meeting  the  demands  of 
modem  flight- testing.  There  is  an  escalating  amount  of  data  that  needs  to  be  transmitted 
to  ensure  safety  of  flight  and  monitor  vehicle  performance,  and  mounting  pressure  to 
perform  testing  faster  and  more  efficiently.  In  addition,  the  portion  of  the  radio 
frequency  spectrum  allotted  to  flight  testing  shrank  significantly  in  2001  when  these 
frequencies  were  reallocated  to  support  commercial  telecommunications  satellites.  For 
these  reasons,  efforts  are  underway  to  improve  TM  systems  at  DoD  test  ranges.  Over  the 
past  15  years,  the  Consultative  Committee  for  Space  Data  Systems  (CCSDS)  has 
recommended  the  establishment  of  a  common  framework  for  data  services  of  spacecraft 
telemetry  systems.  The  CCSDS  recommendation,  which  was  officially  named  a  Range 
Commander's  Council/Inter-Range  Instrumentation  Group  (RCC/IRIG)  standard  in  2001, 
has  been  in  limited  use  in  the  space  community  and  will  likely  be  applied  in  the  test  range 
community.  The  overall  objective  of  this  project  was  to  evaluate  the  practical  use  of 
CCSDS  in  the  DoD  test  range  environment  and  determine  the  configuration  of  CCSDS 
protocol  parameters  that  would  maximize  CCSDS  performance  based  on  mission 
requirements.  A  secondary  objective  was  to  compare  the  performance  of  CCSDS  to  the 
Asynchronous  Transfer  Mode  (ATM)  protocol  in  order  to  substantiate  further  exploration 


xi 


of  using  the  ATM  protocol,  alone  or  in  conjunction  with  CCSDS,  in  future  DoD 
telemetry  systems. 

Modeling  and  simulation  of  the  CCSDS  packet  telemetry  protocol  was  conducted 
at  the  Air  Force  Institute  of  Technology  at  Wright- Patterson  AFB,  during  Jul-Nov  2000. 
This  work  showed  a  correlation  between  three  specific  CCSDS  protocol  parameters  and 
the  resulting  throughput  and  data  quality  performance  of  the  protocol.  Flight  tests  were 
then  conducted  by  the  USAF  Test  Pilot  School  at  the  Air  Force  Flight  Test  Center 
(AFFTC),  Edwards  AFB,  CA,  from  5-31  October,  2001,  using  a  Sabreliner  T-39A 
passenger  jet.  Preliminary  results  confirmed  the  correlation  between  the  previously 
identified  CCSDS  parameters  and  the  resulting  protocol  performance.  After  further 
testing,  the  team  was  able  to  narrow  in  on  the  combination  of  parameters  that  would 
maximize  data  throughput,  data  quality,  or  provide  a  combined  "best  of  both  worlds" 
solution.  In  general,  flight  test  results  matched  those  of  the  modeling  and  simulation 
work. 


Finally,  data  collected  with  the  CCSDS  parameters  set  to  mimic  the  data-to- 
overhead  ratio  of  the  ATM  protocol  indicated  that  the  throughput  and  data  quality 
performance  of  the  ATM  protocol  is  sufficiently  close  to  that  of  the  CCSDS  protocol  to 
warrant  further  investigation  of  using  the  ATM  protocol  in  the  test  range  environment. 
Unlike  CCSDS,  ATM  offers  the  military  user  interoperability  with  civilian 


systems/networks . 


EVALUATION  AND  MISSION- SPECIFIC  OPTIMIZATION  OF  CONSULTATIVE 


COMMITTEE  FOR  SPACE  DATA  SYSTEMS  (CCSDS)  PACKET  TELEMETRY 

PROTOCOL  RECOMMENDATION 


CHAPTER  I  -  BACKGROUND  &  PROBLEM  STATEMENT 


1.1  Background 

The  sampled  data  system  technology  used  in  telemetry  systems  within  the 
Department  of  Defense  test  community  is  more  than  40  years  old  [14].  Figure  1 
illustrates  the  current  Pulse  Code  Modulation  (PCM)  telemetry  scheme.  Typically, 
multiple  data  sources  within  the  test  vehicle  each  produce  and  transfer  a  bit  stream  of 
data  into  an  on-board  multiplexer.  Operating  in  a  Time  Division  Multiple  Access 
(TDMA)  mode,  the  multiplexer  organizes  the  incoming  bit  streams  into  major  frames 
consisting  of  a  number  of  minor  frames  (up  to  256  minor  frames  combine  to  form  one 
major  frame).  The  frame  structure  is  preprogrammed  for  each  mission  and  relatively 
static  between  missions.  Minor  frames  can  range  in  size  from  a  few  hundred  bits  up  to  8 
Kbits,  but  once  the  size  is  set  it  cannot  be  easily  changed.  The  minor  frame  consists  of  a 
header  (primarily  a  synchronization  pattern)  and  a  fixed  number  of  payload  slots.  Each 
data  source  on  the  aircraft  is  assigned  one  or  more  slots  in  the  major  frame.  As  with 
frame  structure,  slot  assignments  are  preprogrammed  and  fixed  during  a  mission.  If  a 
particular  data  source  is  not  operational,  or  is  not  producing  valid  data  at  some  point  in 
time,  its  assigned  slots  are  filled  with  arbitrary  filler  bits. 
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In  order  to  maintain  a  continuous  flow  of  bits,  the  multiplexer  is  clocked  at  the  bit 
rate  of  the  RF  downlink.  The  bit  rate  of  the  RF  link  can  vary  from  1-20  Mbps,  but  for 
practical  considerations,  including  range  spectrum  allocations,  the  link  typically  operates 
at  1-5  Mbps.  Once  received,  minor  frames  are  sent  to  a  de- multiplexer  where  individual 
data  streams  are  reconstructed  and  forwarded  to  the  appropriate  data  acquisition 
applications.  There  are  no  redundant  transmission  capabilities;  if  critical  data  is 
corrupted  or  lost  during  the  downlink  process,  on-board  recorders  are  used  to  reconstruct 
the  bit  stream,  or  if  they  are  not  available,  the  flight  test  is  repeated  to  recreate  the  data. 


Figure  1.  Current  DoD  Telemetry  System 

There  are  several  drawbacks  to  the  current  PCM  telemetry  scheme.  The  static 
nature  of  the  minor  frames  (specifically,  the  permanent  slot  assignments  and  use  of  filler 
bits)  is  inefficient  and  limits  effective  data  throughput.  Prioritization  is  accomplished 
only  by  assigning  in  advance  a  large  number  of  slots  to  a  particular  data  source.  The 
allocated  RF  bandwidth  is  invariably  less  than  required  and  continues  to  shrink  as 
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portions  of  the  DoD  Test  and  Evaluation  frequency  bands  are  reallocated  to  support 
commercial  telecommunications.  In  an  unmodified  PCM  system,  all  data  from  all 
sources  is  transmitted  to  ground  sites  whether  or  not  that  data  is  being  used  or  requested. 
Additionally,  any  data  that  is  lost  or  cormpted  during  transmission  must  be  restored  from 
tape  or  recreated.  While  in  flight,  users  on  the  ground  have  no  means  of  re- tasking  or 
adjusting  data  sources  on  the  aircraft,  which  often  means  additional  costly  flight  tests. 

Although  there  are  many  areas  where  improvements  can  be  made,  the  focus  of 
this  research  is  the  replacement  of  the  major  and  minor  frames  with  a  modem,  more 
efficient  packet  telemetry  scheme.  Over  the  past  15  years,  the  Consultative  Committee 
for  Space  Data  Systems  (CCSDS)  has  recommended  the  establishment  of  a  common 
framework  for  data  services  of  spacecraft  telemetry  systems  [4].  The  CCSDS 
recommendation,  which  became  a  Range  Commander's  Council/Inter- Range 
Instrumentation  Group  (RCC/IRIG)  standard  in  2001,  has  been  in  limited  use  in  the  space 
community  and  will  likely  be  applied  in  the  test  range  community.  Therefore,  CCSDS  is 
the  packet  telemetry  scheme  examined  in  this  thesis  study.  The  conclusions  reached  in 
this  study  can  be  directly  applied  to  other  areas  of  current  research,  including  efforts  to 
apply  Asynchronous  Transfer  Mode  (ATM)  technology  to  telemetry  at  various  test 
ranges  [13]. 

1.2  Problem  Statement 

The  goal  of  this  research  is  to  evaluate  the  practical  use  of  the  Consultative 
Committee  for  Space  Data  Systems  (CCSDS)  packet  telemetry  standard  in  the 
Department  of  Defense  (DoD)  test  range  environment.  Three  CCSDS  parameters  have 
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been  identified  as  having  a  strong  influence  on  the  protocol's  performance.  These 
parameters  are  transfer  frame  size,  source  packet  length,  and  Reed- Solomon  error- 
correction  encoding.  The  effects  these  parameters  have  on  system  throughput  and  data 
quality  is  established  and  guidance  provided  to  allow  optimization  of  the  protocol  to  meet 
user  specified  quality  of  service  requirements.  CCSDS  protocol  performance  is  also 
compared  to  that  of  the  Asynchronous  Transfer  Mode  (ATM)  protocol  in  an  attempt  to 
substantiate  further  exploration  into  using  the  ATM  protocol,  either  alone  or  in 
conjunction  with  CCSDS,  in  future  DoD  telemetry  systems. 

1.3  Scope 

Data- producing  subsystems  on  an  aircraft  using  the  CCSDS  standard  generate 
variable  length  source  packets.  A  CCSDS  processor  then  segments  the  packets  to 
produce  a  stream  of  fixed  length  transfer  frames ,  which  are  subsequently  transmitted  to 
the  ground.  Generally,  this  data  has  certain  transfer  requirements,  or  Quality  of  Service 
(QoS)  parameters,  such  as  throughput  and  reliability.  Depending  on  the  type  of  data 
being  transferred,  these  QoS  parameters  can  vary.  For  example,  video  data  should  be 
transferred  with  minimum  delay  but  can  tolerate  occasional  data  losses.  On  the  other 
hand,  memory  data,  such  as  GPS  location  data,  cannot  tolerate  any  loss  of  data  but  can 
usually  accept  some  delay  [23].  Performance  of  the  system  can  be  defined  according  to 
several  metrics.  These  include,  but  are  not  limited  to,  effective  data  throughput,  data 
quality,  channel  utilization,  and  data  latency.  The  focus  of  this  research  is  choosing  a 
priori  the  most  advantageous  CCSDS  source  packet  and  transfer  frame  lengths,  with 
respect  to  throughput  and  data  quality  for  a  given  mission.  Given  the  limited  RF 
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spectrum  allocation,  users  in  the  test  range  community  have  a  strong  interest  in 
maximizing  channel  usage  [13].  This  research  therefore  concentrates  only  on  those 
combinations  of  CCSDS  parameters  that  provide  near- 100%  channel  utilization1.  Data 
latency  is  not  directly  evaluated  in  this  study  although  it  would  be  an  important  factor  in 
real-time  applications. 

Evaluation  of  source  packet  and  transfer  frame  length  versus  throughput  and  data 
quality  is  done  via  computer  simulation  using  OPNET  network  simulation  tools  [15].  A 
model  of  the  current  telemetry  system  is  built  in  OPNET  incorporating  representative 
channel  error-rate  characteristics  of  Edwards  Air  Force  Base  (AFB),  California.  Varying 
source  packet  and  transfer  frame  lengths  are  evaluated  as  detailed  in  Chapter  III. 
Validation  of  the  study's  results  is  carried  out  via  flight  test  as  part  of  the  USAF  Test  Pilot 
School  (TPS)  curriculum.  The  Advanced  Range  Telemetry  (ARTM)  office  located  at 
Edwards  AFB  is  heading  up  the  overall  project  and  was  responsible  for  assembly  of  the 
actual  telemetry  system  model  used  for  the  flight  test. 

1.4  Players 

1.4.1  DoD  Test  Range:  This  community  encompasses  the  personnel  and 
resources  responsible  for  the  design,  execution,  and  report  of  flight  test  projects 
conducted  within  the  DoD  Design  Test  and  Evaluation  (DT&E)  and  Operational  Test  and 
Evaluation  (OT&E)  areas  of  responsibility.  The  test  range  community  includes  all 
government  and  military  organizations  involved  with  the  test  and  evaluation  of  military 


1  In  practice  it  was  possible  to  achieve  between  98.9  -  99.99  channel  utilization. 
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aircraft  and/or  their  weapons  systems,  avionics,  navigation,  or  the  software  used  by  these 
systems. 

1.4.2  ARTM  JPO :  The  ARTM  Joint  Program  Office  (ARTM  JPO),  located  at 
Edwards  AFB,  was  created  to  develop,  test,  and  evaluate  technology  that  improves  the 
efficiency,  quality,  and  utility  of  aeronautical  telemetry.  The  ARTM  team  works  closely 
with  the  Range  Commander's  Council,  which  represents  all  DoD  test  ranges,  to  keep  the 
test  community  apprised  of  its  findings.  The  technology  developed  by  ARTM  will  be 
used  at  18  different  Air  Force,  Army,  and  Navy  ranges. 

1.4.3  Test  Pilot  School:  The  flight  test  was  conducted  by  the  NEED  INFO  test 
team.  United  States  Air  Force  Test  Pilot  School  (USAF  TPS)  Class  01 A  at  USAF  Flight 
Test  Center  (AFFTC),  Edwards  AFB,  CA,  from  5-31  October,  2001.  The  Responsible 
Test  Organization  (RTO)  was  the  412th  Test  Wing,  Edwards  AFB,  CA. 

1.5  Objectives 

The  results  of  the  CCSDS  evaluation  are  evaluated  in  three  ways:  maximum 
throughput  (e.g.,  for  "video  data"),  maximum  data  quality  (e.g.,  for  "memory  data"),  and 
achieve  the  best  tradeoff  between  throughput  and  data  quality  (e.g.,  for  missions 
involving  both  "video"  and  "memory"  data).  The  results  of  the  study  will  allow  a  test 
designer  to  make  the  following  pre-mission  decisions: 

•  Based  on  the  type  of  data  to  be  transmitted,  what  combination  of  source 
packet  length,  transfer  frame  length,  and  Reed- Solomon  encoding  will 
maximize  effective  throughput? 
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•  Based  on  the  type  of  data  to  be  transmitted,  what  combination  of  source 
packet  length,  transfer  frame  length,  and  Reed- Solomon  encoding  will 
maximize  the  quality  of  the  received  data? 

•  Based  on  the  type  of  data  to  be  transmitted,  what  combination  of  source 
packet  length,  transfer  frame  length,  and  Reed- Solomon  encoding  will  give 
the  best  tradeoff  between  effective  throughput  and  data  quality? 

1.6  Document  Organization 

Chapter  II  establishes  the  background  knowledge  needed  to  understand  the 
CCSDS  packet  telemetry  protocol.  In  addition,  this  chapter  lays  the  foundation  for 
modeling  the  channel  error-rate  characteristics  at  Edwards  AFB  and  discusses  the  results 
of  previous  efforts  in  packet  telemetry.  Chapter  III  outlines  the  methodology  to  be 
followed  in  developing  the  computer  telemetry  model  in  OPNET.  Specifically,  this 
chapter  discusses  the  experimental  factors  (source  packet  length,  transfer  frame  length, 
and  Reed- Solomon  encoding)  and  the  two  measures  of  performance  (effective  data 
throughput  and  data  quality).  It  also  discusses  simulation  length,  model  verification,  and 
model  validation.  Chapter  IV  details  the  experimental  results  obtained  from  the 
methodology  followed  in  Chapter  III.  Chapter  V  summarizes  the  findings  indicated  in 
Chapter  IV  and  presents  some  recommendations  for  future  study.  Chapter  VI 
summarizes  the  results  of  the  flight  test  conducted  at  Edwards  AFB  to  validate  the  results 
of  the  computer  simulation.  Finally,  Chapter  VII  offers  some  overall  conclusions  and 
recommendations  from  the  entire  research  effort.  Details  of  the  construction  and 
operation  of  the  OPNET  model  are  given  in  Appendices  A  -  D.  Appendices  E  and  F  list 
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the  simulation  and  flight  test  results,  respectively,  in  their  entirety.  Finally  Appendix  G 
provides  a  list  of  acronyms  used  throughout  this  report. 
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CHAPTER  II  -  LITERATURE  REVIEW 


2.1  Introduction 

The  use  of  the  CCSDS  packet  telemetry  protocol  in  the  test  range  environment 
will  be  a  significant  upgrade  to  the  nearly  40- year-old  technology  used  presently.  This 
chapter  investigates  the  telemetry  downlink  process  and  looks  at  how  CCSDS  fits 
naturally  into  this  scheme.  A  detailed  description  of  the  CCSDS  protocol  is  provided,  as 
well  as  a  look  into  previous  work  done  in  the  area  of  packet  protocol  performance. 

2.2  CCSDS  Packet  Telemetry  Scheme 

The  purpose  of  a  telemetry  system  is  to  reliably  and  transparently  convey 
measurement  information  from  a  remotely- located  data- generating  source  to  users 
located  in  space  or  on  Earth.  Packet  telemetry  represents  an  evolutionary  step  from  the 
traditional  Time-Division  Multiplex  method  of  transmitting  data  from  aircraft  sources  to 
users  on  the  ground.  As  stated  in  the  CCSDS  100.0-G-l  Green  Book  [6],  the  Packet 
Telemetry  process  involves  the  following  two  steps : 

•  Encapsulating,  at  the  source,  observational  data,  thus  forming  an  autonomous 
packet  of  information  in  real-time  on  the  aircraft,  and 

•  Providing  a  standardized  mechanism  whereby  autonomous  packets  from  multiple 
data  sources  on  the  aircraft  can  be  inserted  into  a  common  frame  structure  for 
transfer  to  the  ground  through  noisy  data  channels,  and  delivered  to  facilities 
where  the  packets  may  be  extracted  for  delivery  to  the  user. 


9 


2.1.1  Data  Organized  Into  Source  Packets.  Data  to  be  transmitted  between 
sender  and  receiver  is  organized  into  source  packets.  Each  packet  consists  of  a  48-bit 
header  and  variable  length  data  field.  It  is  the  responsibility  of  the  application  producing 
the  data  to  optimize  the  size  and  structure  of  the  data  set  with  only  a  few  restrictions.  A 
source  packet  must  consist  of  at  least  seven  and  no  more  than  65,542  bytes,  allowing  for 
data  of  one  to  65,536  bytes.  Idle  data  may  be  inserted  when  a  packet  is  created  with 
insufficient  data  to  completely  fill  the  source  packet  data  field,  or  when  a  source  packet 
must  be  produced  in  order  to  maintain  the  continuous  channel  data  rate.  A  packet 
containing  only  idle  data  is  referred  to  as  an  idle  packet.  A  diagram  of  the  source  packet 
structure  is  given  in  Figure  2. 
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Figure  2.  Source  Packet  Format  [4] 


The  packet  primary  header  is  mandatory  and  consists  of  the  following  four  fields: 


version  number  (3  bits),  packet  identification  (13  bits),  packet  sequence  control  (16  bits), 
and  packet  data  length  (16  bits).  The  version  number  field  is  reserved  for  the  possible 


creation  of  other  data  structures  in  the  future.  As  such,  version  number  is  set  to  "000"  to 
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identify  the  data  unit  as  a  source  packet.  The  packet  identification  bits  are  used  to 
identify  the  type  of  packet  (1  bit,  set  to  "0"  to  indicate  telemetry  data  units),  indicate 
whether  or  not  a  packet  includes  a  secondary  header  (1  bit,  set  to  "1"  if  secondary  header 
is  present),  and  provide  information  on  the  source  of  the  data  (11  bits).  Identification  of 
the  data  source  (i.e.,  application  process)  is  tailored  to  local  mission  needs  and  is 
therefore  assigned  by  mission  management.  The  secondary  header  is  mandatory  if  no 
source  data  field  is  present;  otherwise  it  is  optional.  This  optional  header  provides  a 
means  for  placing  ancillary  data  (time,  internal  data  field  format,  spacecraft 
position/altitude,  etc.)  within  a  source  packet.  Use  of  the  optional  header  is  mission 
specific.  The  bytes  making  up  the  optional  header,  as  determined  in  [4],  are  taken  from 
the  total  possible  data  field  bytes  (i.e.,  if  the  maximum  possible  data  field  size  was  65,536 
bytes,  the  inclusion  of  a  six  byte  optional  header  would  reduce  the  maximum  possible 
data  field  size  to  65,530  bytes).  The  packet  sequence  control  bits  provide  a  sequential 
count  of  packets  generated  with  the  same  application  process  identifier.  It  also  includes 
an  optional  grouping  feature  which,  when  applied,  provides  information  on  the  position 
of  a  source  packet  within  a  group  of  packets.  Grouping  flags  make  up  2  bits  of  the  packet 
sequence  control  field,  and  the  source  sequence  count  is  14  bits.  The  source  sequence 
count  is  a  sequential  binary  count  (modulo  16384).  It  is  normally  used  in  conjunction 
with  a  time  code  in  the  secondary  header2.  The  16-bit  packet  data  length  field  contains  a 
binary  number  equal  to  the  number  of  bytes  in  the  packet  data  field  minus  one.  The  value 
ranges  from  0  to  65,535  bytes. 

2  Time  codes  consist  of  an  optional  P-Field  (Preamble  Field),  which  identifies  the  time  code  and  its 
characteristics,  and  a  mandatory  T-Field  (Time  Field).  Examples  of  time  codes  are  CCSDS  Unsegmented 
Time  Code  and  CCSDS  Day  Segmented  Time  Code.  Examples  of  characteristics  are  ambiguity  period, 
epoch,  length,  and  resolution  [4]. 


11 


2.1.2  Source  Packets  Combine  To  Form  Transfer  Frames.  Multiple 
asynchronous  application  processes  on-board  an  aircraft  generate  variable -length  source 
packets  at  different  rates.  These  source  packets  are  then  multiplexed  together  into  a 
synchronous  stream  of  fixed- length  transfer  frames  for  reliable  transmission  to  the 
ground  [4].  Specifically,  the  transfer  frame  is  the  data  structure  used  to  transmit  source 
packets,  idle  data,  and  privately- defined  data  over  the  telemetry  downlink.  A  transfer 
frame  consists  of  the  following  elements:  primary  header  (mandatory  -  48  bits), 
secondary  header  (optional  -  up  to  512  bits),  data  field  (mandatory  -  variable  length), 
operational  control  field  (optional  -  32  bits),  and  a  frame  error  control  field  (mandatory  if 
Reed-Solomon  Encoding  is  not  applied,  otherwise  optional,  16  bits).  Frame  length  is 
constant  throughout  the  period  of  data  transmission.  The  Telemetry  Channel  Code  Green 
Book  [6]  issued  in  1987  limited  the  frame  length  to  8920  bits. 

All  transfer  frames  with  the  same  transfer  frame  version  number  (described 
below)  and  the  same  aircraft4  identifier  (described  in  [4])  on  the  same  physical  channel 
constitute  a  master  channel.  In  most  cases,  the  master  channel  will  be  identical  to  the 
physical  channel.  If,  however,  the  physical  channel  also  carries  transfer  frames  with 
other  aircraft  identifiers,  a  distinction  between  master  channel  and  physical  channel  is 
necessary  [4].  A  master  channel  is  composed  of  up  to  eight  virtual  channels.  The  use  of 
virtual  channels  allows  multiple  packet-producing  sources  to  effectively  be  granted 
exclusive  access  to  a  physical  channel  by  assigning  them  transmission  capacity  on  a 
frame-by-frame  basis.  Each  transfer  frame  belongs  to  one  of  the  up  to  eight  virtual 

3  Privately  defined  data  is  specialized  high-rate  data  or  other  data  not  suitable  for  CCSDS  source  packet 
structuring  [4]. 

4  The  CCSDS  information  has  been  modified  by  using  the  term  "aircraft"  in  place  of  "spacecraft”  in  order 
to  more  directly  apply  the  CCSDS  recommendation  to  the  flight  test  application. 
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channels  on  one  master  channel.  Once  created,  virtual  channels  exist  until 
changed/deleted  by  the  user.  The  virtual  channels  are  constant  during  the  period  of  data 
transmission. 

Figure  3  illustrates  the  transfer  frame  format.  The  48-bit  transfer  frame  primary 
header  consists  of  the  following  five  fields:  version  number  (2  bits),  frame  identification 
(14  bits),  master  channel  frame  count  (8  bits),  virtual  channel  frame  count  (8  bits),  and 
data  field  status  (16  bits).  The  version  number  bits  are  set  to  "00"  to  identify  the  data 
unit  as  a  transfer  frame.  The  frame  identification  field  is  further  divided  into  an  aircraft 
identifier  (10  bits),  virtual  channel  identifier  (3  bits),  and  an  operational  control  field  flag 
(1  bit).  This  field  identifies  the  source  of  the  transfer  frame,  specifies  which  virtual 
channel  the  frame  belongs  to,  and  provides  information  on  the  format  of  the  frame.  A 
more  complete  description  of  these  three  sub -fields  can  be  found  in  the  CCSDS  Packet 
Telemetry  Blue  Book  [4].  The  master  channel  frame  count  is  a  sequential  binary  count 
(modulo  256)  of  each  transfer  frame  transmitted  in  a  particular  master  channel. 

Similarly,  the  virtual  channel  frame  count  is  a  sequential  binary  count  (modulo  256)  of 
each  transfer  frame  transmitted  in  a  particular  virtual  channel  of  a  master  channel.  The 
purpose  of  the  master  channel  frame  count  is  to  provide  a  running  count  of  the  frames 
transmitted  through  the  same  master  channel.  The  virtual  channel  frame  count  provides 
individual  accountability  for  each  of  the  virtual  channels  (maximum  of  eight).  The  16 
data  field  status  bits  are  further  divided  into  a  secondary  header  flag  (1  bit), 
synchronization  flag  (1  bit),  packet  order  flag  (1  bit),  segment  length  identifier  (2  bits), 
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5  If  Reed-Solomon  encoding  is  not  used,  the  2-byte  frame -error  control  field  must  be  used.  If  Reed-Solomon  encoding  is  used,  160  check  bytes  are 
appended  to  the  transfer  frame  and  the  frame -error  control  field  is  not  used. 


and  first  header  pointer  (11  bits).  Again,  a  more  complete  description  of  these  sub- fields 
can  be  found  in  the  CCSDS  Packet  Telemetry  Blue  Book  [4]. 

If  present,  the  transfer  frame  secondary  header  is  used  to  carry  fixed- length 
mission-specific  data.  It  consists  of  an  identification  field  (8  bits)  and  a  data  field  (up  to 
504  bits).  The  secondary  header  is  associated  with  either  a  master  or  virtual  channel. 

The  transfer  frame  data  field  is  used  to  carry  the  data  to  be  transmitted.  It  can 
vary  in  length  from  one  to  1107  bytes.  This  number  is  reduced  if  the  optional  transfer 
frame  header  fields  are  used. 

The  optional  operational  control  field  is  used  to  provide  the  status  of 
telecommand  or  other  aircraft  operations  activities.  If  present,  this  field  will  occur  in 
every  transfer  frame  transmitted  through  either  a  master  or  virtual  channel  throughout  the 
mission  phase. 

The  purpose  of  the  2-  byte  frame  error  control  field  is  to  detect  any  errors 
introduced  into  the  frame  during  the  transmission  and  data  handling  process.  If  this 
optional  field  is  present,  it  will  occur  in  every  transfer  frame  transmitted  within  the  same 
master  channel  throughout  the  mission  phase. 

2.1.3  Telemetry  Data  Flow.  Figure  4  illustrates  data  flow  in  the  CCSDS 
packet  telemetry  scheme.  At  the  top  of  the  diagram,  multiple  on-board  data  sources  are 
producing  source  packets.  These  source  packets  are  then  multiplexed  into  transfer  frames 
of  several  virtual  channels.  The  transfer  frames  are  subsequently  transmitted  to  the 
ground  over  the  physical  channel  using  appropriate  synchronization  techniques.  The  use 
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of  virtual  channels  allows  the  data  to  be  organized  by  data  type,  prioritized  according  to 
mission  requirements,  or  separated  according  to  source  and  destination. 

The  specific  role  the  virtual  channels  will  play  is  outside  the  scope  of  this  research 
and  does  not  affect  its  results.  More  information  on  intelligent  selection  of  data  streams 
to  reduce  required  telemetry  downlink  bandwidth  is  in  [19].  For  this  research,  it  is 
assumed  that  multiple  data  sources  are  represented  by  one  collective  data  source 
producing  source  packets  into  a  single  virtual  channel.  These  source  packets  are  then 
organized  into  transfer  frames  on  a  first- come -first- serve  basis  and  transmitted  over  the 
physical  channel  to  the  ground.  On  the  ground  the  process  is  reversed;  the  transfer 
frames  are  disassembled  into  the  original  source  packets,  which  are  then  delivered  to  one 
or  more  sink  processes.  Figure  5  shows  the  packet  telemetry  scheme  redrawn  to  reflect 
the  telemetry  flow  model  used  in  this  research.  For  this  investigation,  performance 
measurements  were  taken  starting  from  the  point  the  source  packets  are  generated  to  the 
point  where  the  transfer  frames  arrive  on  the  ground  and  the  source  packets  are 
reconstructed.  Processing  time  on  the  ground  is  application- dependent  and  therefore  not 
taken  into  account. 


16 


generate 

source 


Multiplex  Source 
Packets  into  , 

Transfer  Frames  of  l 
Virtual  Channels 

Multiplex  . 

Virtual  Channels  I 
into 

Master  Channel 


Source  I 

AP 

0 

AP 

1 

AP 

2 

Source  III 

AP 

5 

AP 

6 

AP 

7 

Source  IV 

AP  AP  AP 
9  10  11 


Apply  Coding 
and 

modulate  RF 

Demodulate 
RF  and 
decode 


Demultiplex 
Virtual  Channels 


Master  Channel 


Physical  Channel 


Physical  Channel 


Master  Channel 


DATA  UNITS 


Source  Packets 


Transfer  Frames 


Synchronous  Stream 
of  Transfer  Frames 


Synchronous  Stream 
of  Transfer  Frames 


Demultiplex 

Packets 


Distribute  Packets  to 
one  or  more 
Sink  Processes 


1  vco 

II 

VC  1 

II  VC  2  1 

1 .. .. 

..  i 

i .. .. 

1  ....  1 

Transfer  Frames 


Source  Packets 


Source  Packets 


Figure  4.  Telemetry  Data  Flow  [2] 


2.3  Channel  Characterization 

The  performance  of  any  telemetry  downlink  scheme  is  heavily  influenced  by  the 
bit  error  characteristics  of  the  physical  channel.  The  dominant  source  of  bit  errors  and 
short  term  link  failures  at  Edwards  AFB  are  "clusters"  of  severe  error  burst  activity 
caused  by  fading,  poor  antenna  patterns,  multipath  interference,  or  shadowing  [18,  20]. 
The  bit  error  rate  (BER)  of  the  typical  1-20  Mb/sec  RF  link  can  vary  from  a  relatively 
clean  10"  “  to  an  essentially  unusable  0.5.  The  experimental  model  must,  therefore, 
incorporate  channel  characterization  in  order  to  accurately  determine  the  effective 
performance  of  a  data  transfer. 
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Figure  5.  Telemetry  Data  Flow  Used  In  Research  Work 


Both  [18,  20]  investigate  link  availability  and  burst  error  analysis  at  Edwards 
AFB.  Their  results  indicate  that  the  channel  errors  occur  in  bursts,  rather  than  randomly, 
and  are  due  to  multipath  interference  which  occurs  at  seemingly  random  intervals.  To 
accurately  represent  the  bit  error  activity,  real-time  bit  error  activity  sampled  from  the 
Edwards  AFB  test  range  were  incorporated  into  the  OPNET  simulation  model. 
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2.4  Modeling  of  the  Telemetry  Downlink 


The  telemetry  downlink  can  be  modeled  as  a  point-to-point  communication 
system  using  a  two- layer  protocol  architecture.  The  communication  system  consists  of 
two  nodes  in  a  simplex  environment.  Communication  is  from  the  airborne  node  to  the 
ground  node  with  no  data  retransmission  or  data  acknowledge  capabilities.  Multiple 
users  (on-board  data  sources)  use  the  sender  (airborne)  node  to  transmit  data  messages  to 
the  receiver  (ground)  node.  The  modified  two-layer  protocol  model  is  shown  in  Figure  6. 
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Figure  6.  Two-Layer  Protocol  Architecture  [7] 

This  model  is  analogous  to  the  application  and  transport  layers  in  the  OSI 
reference  model.  Generated  data  is  split  into  source  packets  by  each  on-board  data 
source,  and  protocol  control  information  (PCI),  namely  the  48-bit  source  packet  header, 
is  prepended  in  the  application  layer.  At  the  transport  layer,  source  packets  are 
segmented  into  transfer  frames  and  another  48-bit  header  is  added  to  each.  Since  queuing 
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and  processing  at  each  layer  contributes  to  the  overall  transmission  delay,  the  system 
could  be  analyzed  using  a  multi-queue  model  instead  of  a  single  queue  as  was  done  in 
[11].  However,  since  the  basis  of  performance  measurements  is  the  entry  of  source 
packets  into  the  virtual  channel,  the  architecture  simulated  in  OPNET  consists  of  only  the 
transport  layer  and  is,  therefore,  modeled  as  a  single  queue.  Delays  due  to  segmentation 
of  data  into  source  packets  and  the  assembly  of  source  packets  into  transfer  frames  are  a 
function  of  the  speed  of  the  computer  equipment  and  are  assumed  to  be  negligible 
compared  to  the  transmission  delay,  which  is  estimated  at  1.75e-05  seconds  (c.f., 
Appendix  A).  All  transfer  frames  follow  the  same  path,  hence  they  arrive  at  the 
destination  node  in  the  same  order  they  left  the  source  node.  Using  standard  queuing 
notation,  the  system  can  be  modeled  as  shown  in  Figure  7. 
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Figure  7.  Queuing  Model 
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2.5  Reed-Solomon  Encoding 


The  Reed- Solomon  code  is  a  powerful  burst  error  correcting  code  with  an 
extremely  low  undetected  error  rate  [6].  The  code  contained  in  the  CCSDS 
recommendation  is  a  (255,  223)  Reed-Solomon  code,  meaning  that  225  output  bytes 
result  from  an  encoding  of  223  input  bytes.  This  will  be  described  in  more  detail  shortly. 
The  code  is  a  non-binary  code.  Each  member  of  its  coding  alphabet  is  one  of  256 
elements  of  a  finite  field  rather  than  zero  or  one.  A  string  of  eight  bits  is  used  to 
represent  elements  in  a  field  so  that  the  output  of  the  encoder  still  looks  like  binary  data. 
The  Reed-Solomon  code  is  also  systematic.  This  means  that  some  portion  of  the 
codeword  contains  the  input  data  in  unalterable  form.  In  this  case,  the  first  223  bytes  are 
the  unaltered  input  data  followed  by  32  check  bytes.  This  (255,  223)  code  is  capable  of 
correcting  up  to  16  byte  errors  in  each  codeword. 

In  addition,  the  Reed-Solomon  codewords  can  be  byte  interleaved.  This  separates 
bytes  in  a  codeword  making  it  less  likely  that  burst  errors  disturb  more  than  one  byte  in 
any  codeword,  thus  improving  the  performance  of  the  code.  An  interleaving  depth  of 
five  was  chosen  by  the  Consultative  Committee  for  Space  Data  Systems  because  it  results 
in  performance  that  is  virtually  indistinguishable  from  a  depth  of  infinity.  Further,  a 
depth  of  five  results  in  a  codeblock  (one  codeblock  equals  a  set  of  five  codewords  plus 
the  check  symbol  field)  which  is  a  good  compromise  considering  ease  of  handling,  data 
outages  and  frame  synchronization  rate.  Defined  in  this  manner,  a  codeblock  is 
synonymous  with  a  transfer  frame. 
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The  following  summarizes  the  use  of  Reed- Solomon  encoding  in  the  CCSDS 
recommendation: 

One  RS  codeword  =  223  data  bytes  +  32  check  bytes 

With  the  interleave  set  to  five, 

One  RS  codeblock  =  5  x  (One  RS  codeword) 

=  5  x  (223  data  bytes  +  32  check  bytes) 

=  1115  data  bytes  +  160  check  bytes 

A  transfer  frame  is  synonymous  with  a  codeblock,  therefore  a  transfer  frame  (with 
Reed-Solomon  turned  ON)  consists  of  up  to  1115  bytes  (includes  header  information) 
and  160  bytes  of  error  detection/correction  information. 

The  same  encoding  and  decoding  hardware  can  also  implement  a  shortened 
version  of  the  codeblock.  This  is  accomplished  by  assuming  the  remaining  bytes  are 
fixed,  in  this  case  they  are  assumed  to  be  all  zero.  This  virtual  zero  fill  allows  the  transfer 
frame  length  to  be  tailored  to  suit  a  particular  mission.  In  short  this  means  that  the 
transfer  frame  length  can  be  less  than  1115  bytes.  All  160  check  bytes  are  still  required, 
however,  regardless  of  the  payload  length. 

If  Reed-Solomon  is  turned  OFF,  the  160  bytes  of  check  data  are  replaced  with 
two  CRC  bytes  and  four  bytes  are  appended  to  each  transfer  frame  (regardless  of  whether 
Reed-Solomon  is  ON/OFF)  for  the  purpose  of  frame  synchronization.  The  following  two 
transfer  frame  configurations  are  possible: 
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•  No  Reed-Solomon: 


synchronization  +  transfer  frame 

v _ _ _ j  \ _ _ _ j 

v  v 

4  bytes  8-byte  header  +  up  to  1 107  bytes  of  data 


•  With  Reed-Solomon: 


synchronization 

v _ J 


4  bytes 


+  transfer  frame 
V - v - ' 


+ 


6-byte  header  +  up  to  1109  bytes  of  data 


R-S  check  symbols 

V - v - 7 

160  bytes 


2.6  Previous  Work  In  This  Area 

A  1998  study  by  Chen,  Kimura,  and  Ebihara  [11]  looked  at  optimal  packet  length 
to  minimize  mean  data  transmission  delay  in  a  point-to-point  communication  system  for 
both  two- layer  and  three- layer  protocol  structures.  Their  two- layer  model  consisted  of  a 
network  and  data  link  control  (DLC)  layer,  with  retransmission  occurring  at  the  network 
layer.  Their  model  used  two  M/M/1  queues  with  Poisson-distributed  data  arrival  and 
exponentially- distributed  service  times  at  each  module.  Packet  segmentation  and 
reassembly  delays  were  ignored.  They  found  optimal  packet  length  depended  on  only  the 
mean  packet  length,  average  BER,  and  the  protocol  control  information  (PCI)  length  of 
the  network  layer.  This  relationship  is  shown  in  Equation  (1).  Here,  packets  are 
analogous  to  CCSDS  transfer  frames,  and  PCI  length  analogous  to  CCSDS  source  packet 
length. 
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Optimal  packet  length,  xqpl.  is 


f  1  1 

xOPL  =  min  L,  —  —— - -  +h2  (1) 

^  ln(l  -pe)J 

where,  L  is  the  average  packet  length  in  bits,  pe  is  the  average  BER,  and  h>  is  the  PCI 
length  of  the  network  layer  in  bits. 

The  study  concludes  that  optimal  packet  length  is  most  affected  by  the  BER  of  the 
transmission  media  and  the  mean  packet  length.  Efficiency  and  throughput  of  data 
transmission  was  better  as  the  packet  length  increased.  This  study  did  not  investigate 
burst  error  conditions.  Although  the  model  used  in  [11]  is  not  identical  to  that  used  here 
(the  use  of  M/M/1  queues  does  not  apply  in  the  telemetry  model  and  the  RF  channel 
errors  are  very  bursty  in  nature),  it  is  reasonable  to  predict  similar  results;  specifically 
that  BER  and  source  packet  length  have  a  strong  effect  on  the  recommended  transfer 
frame  length,  and  that  throughput  tends  to  increase  as  transfer  frame  length  increases. 

Unlike  [11],  a  1996  study  by  Hara,  Ogino,  Araki,  Okada,  and  Morinaga  [22] 
specifically  examined  radio  communication  system  performance  in  the  presence  of  burst 
errors  in  a  Rayleigh  channel.  They  proposed  an  efficient  stop-and-wait  automatic  repeat 
request  (SAW-ARQ)  protocol  with  adaptive  packet  length  to  provide  reliable  mobile  data 
packet  transmission.  The  SAW-ARQ  protocol  controls  the  transmitting  packet  length 
according  to  the  time- varying  channel  condition  estimated  by  the  number  of  ACKs 
(acknowledgement  packets)  and  NACKs  (negative -acknowledgment  packets).  As  in 
[11],  this  study  showed  a  strong  correlation  between  channel  bit  error  and  optimal  packet 
length.  Unlike  the  telemetry  model  in  this  project,  the  SAW-ARQ  study  was  able  to 
adjust  packet  length  dynamically  through  the  use  of  control  messages  (i.e.,  ACKs  and 


24 


NACKs)  from  the  receiving  node.  The  duplex-nature  of  their  model  is  a  luxury  not 
currently  afforded  in  the  simplex  telemetry  downlink  model.  Nonetheless,  the  results  of 
this  study  again  indicate  the  necessity  of  accurately  modeling  the  RF  channel  in  the 
OPNET  simulation. 

A  1979  study  by  Minoli  [7]  found  the  optimal  packet  length  to  meet  end-to-end 
delivery  delay  requirements  in  a  single  link  packet  voice  communication.  As  in  the  other 
studies,  this  study  highlights  the  basic  tradeoff  between  longer  packets,  which  increase 
throughput  and  decrease  overhead  percentages,  and  shorter  packets,  which  increase  data 
quality  (thus  reducing  the  number  of  retransmissions  due  to  bit  error).  Minoli  also 
organized  packet  length  results  based  on  typical  operating  conditions  into  a  table  format. 
Given  channel  capacity,  amount  of  packet  overhead  (in  bits),  and  the  digitization  rate,  the 
user  is  presented  with  the  proper  packet  length  to  meet  pre-established  end-to-end 
delivery  requirements. 

2. 7  Summary 

The  CCSDS  packet  telemetry  protocol  represents  a  promising  technology  for  the 
DoD  test  range  community.  Research  and  evaluation  of  telemetry  systems,  and  in 
particular  the  CCSDS  protocol,  is  on-going  at  Edwards  AFB  and  elsewhere.  This  chapter 
has  reviewed  some  of  the  primary  concepts  of  the  telemetry  downlink  and  described  the 
inner  workings  of  the  CCSDS  protocol.  The  next  chapter  will  lay  the  foundation  for 
evaluating  and  optimizing  the  use  of  CCSDS  in  the  test  range  environment  to  satisfy 
mission  requirements. 
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CHAPTER  III  -  METHODOLOGY 


3.1  Introduction 

This  chapter  discusses  the  approach  taken  to  predict  the  performance  of  the 
CCSDS  protocol  in  the  test  range  environment.  The  factors  affecting  protocol 
performance  are  first  discussed  and  simplifying  assumptions  made  to  facilitate 
construction  of  the  computer  model  used  to  simulate  the  downlink  of  telemetry  data  at 
Edwards  AFB.  Next,  the  critical  CCSDS  parameters,  transfer  frame  size,  source  packet 
length,  and  Reed- Solomon  encoding,  are  discussed  along  with  the  primary  measures  of 
performance  used  to  evaluate  protocol  performance,  throughput  and  data  quality.  Finally, 
two  issues  fundamental  to  the  construction  and  use  of  the  computer  model,  namely 
simulation  length  and  characterization  of  the  channel  error,  are  introduced. 

3.2  Description  of  Experiments 

3.2.1  System  Definition.  The  goal  of  this  investigation  is  to  evaluate  the 
performance  of  the  CCSDS  packet  telemetry  standard  in  the  DoD  test  range  environment. 
The  system  consists  of  two  nodes,  an  airborne  node  and  a  ground  node.  The  airborne 
node  generates  source  packets,  constructs  transfer  frames  from  the  source  packets,  and 
transmits  the  transfer  frames  to  the  ground.  The  ground  node  receives  the  transmitted 
transfer  frames,  unpacks  the  source  packets,  and  delivers  the  source  packets  to  the 
appropriate  end  users.  Source  packets  may  be  bigger  or  smaller  than  a  single  transfer 
frame.  The  system  under  investigation  includes  all  the  components  in  the  telemetry 
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downlink  process,  from  the  point  the  source  packets  arrive  to  be  loaded  into  the  transfer 
frames,  to  the  point  the  transfer  frames  arrive  at  the  ground  node  and  the  source  packets 
are  reformed.  This  methodology  is  designed  so  that  the  effects  of  components  outside  the 
defined  system  were  minimized.  The  evaluation  was  performed  using  the  OPNET 
network  modeling  software.  The  results  of  the  software  simulations  were  later  validated 
by  flight  test.  A  description  of  the  OPNET  model  is  in  Appendices  A  and  B. 


3.2.2  Experimental  Parameters 

The  parameters  that  affect  the  performance  of  the  system  include  the  following: 

•  Error  correction  encoding 

•  Source  packet  length 

•  Transfer  frame  length 

•  Channel  BER 

•  Source  packet  generation  rate 

•  Percentage  of  filler  data  in  transfer  frames 

•  Number  of  on-board  data  sources 

•  Speed  of  PCM  equipment 

•  Aircraft  altitude 

•  Antenna  pattern  on  aircraft 

•  Weather 

•  Test  range  location  (i.e.,  Edwards  AFB  versus  Nellis  AFB) 

•  Data  rate  of  RF  downlink  (1-20  Mbps) 

•  Source  packet  overhead 

•  Transfer  frame  overhead 


3.2.3  Experimental  Factors 

The  key  factors  chosen  for  this  investigation  were  the  following: 

•  Error  correction  encoding 

•  Source  packet  length 

•  Transfer  frame  length 
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The  factors  were  chosen  based  on  resource  availability  and  usefulness  of  the 


results  to  the  sponsors.  Each  will  be  discussed  in  further  detail.  The  remaining 
parameters  were  not  chosen  as  factors  for  the  following  reasons. 

•  Bit  error  rate:  Flight  tests  conducted  by  the  ARTM  project  office  have  confirmed 
the  two  primary  sources  of  bit  errors  and  short-term  failure  links  in  the  traditional 
test  corridors  at  Edwards  AFB  are  "error  bursts"  and  "error  clusters".  A 
characterization  of  these  channel  errors  is  given  in  Appendix  A.  A  custom  link 
model  was  built  in  OPNET  to  simulate  the  channel  and  was  used  during  all 
simulation  runs. 

•  Source  Packet  Generation  Rate:  Given  the  limited  RF  spectrum  allocation,  users 
in  the  test  range  community  have  a  strong  interest  in  maximizing  channel  usage 
[13].  Therefore,  only  those  combinations  of  CCSDS  parameters  that  provide 
near- 100%  channel  utilization  are  used.  This  is  accomplished  by  setting  the 
source  packet  generation  rate  to  achieve  as  close  to  100%  channel  utilization  as 
possible.  Typical  channel  utilization  rates  attained  were  on  the  order  of  99.9%. 

•  Percentage  of  filler  data:  This  is  directly  related  to  source  packet  length  and 
source  packet  generation  rate  and  would  therefore  be  redundant. 

•  Number  of  on-board  data  sources:  This  is  related  to  source  packet  generation  rate 
and  would  therefore  be  redundant. 

•  Speed  of  PCM  equipment  at  source  and  destination:  This  is  beyond  the  scope  of 
this  investigation  and  was  assumed  to  be  sufficient. 
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•  Flight  altitude,  Antenna  pattern  on  aircraft.  Weather,  and  Test  range  location: 

The  resources  needed  to  directly  examine  these  parameters  were  not  available. 
Effects  due  to  these  parameters  were  taken  into  account  by  the  channel  BER. 

•  Data  rate  of  RF  downlink:  This  parameter  ranges  in  value  from  1  to  20  Mbps. 

For  this  investigation  the  value  was  held  constant  at  1  Mbps.  This  value  was 
chosen  after  consultation  with  ARTM  to  pick  a  data  rate  compatible  with  the 
equipment  used  during  the  flight  test.  The  data  rate  was  also  used  during  the 
simulations  to  facilitate  a  comparison  of  simulation  and  flight  test  results. 

•  Transfer  Frame  and  Source  packet  overhead:  The  value  of  these  parameters  is 
dictated  by  the  CCSDS  standard.  The  purpose  of  this  investigation  is  to  find  the 
most  efficient  use  of  the  standard,  not  to  alter  it. 

Error  Correction:  While  the  addition  of  error- detection  bits  aids  in  the  determination  of 
whether  the  data  received  on  the  ground  is  "good"  or  "bad",  it  also  increases  transmission 
overhead  and  decreases  the  effective  throughput  of  "good"  data.  Typical  "best  effort" 
systems  have  classically  made  little  use  of  error  checking  due  to  end  users'  opinion  that 
"even  bad  data  is  better  than  no  data  [13]."  The  optional  error- detection  and  correction 
method  in  the  CCSDS  recommendation  is  Reed-Solomon  encoding,  which  is  a  powerful 
burst- error- correcting  code.  A  detailed  description  of  Reed-Solomon  coding  can  be 
found  in  Chapter  II.  If  used,  an  additional  160  bytes  of  check  symbols  must  be  appended 
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to  the  transfer  frame.  If  not  used,  the  2-byte  frame-error  control  field  of  the  transfer 
frame  header  must  be  used. 

Source  Packet  Length:  Data  to  be  transmitted  between  sender  and  receiver  is  organized 
into  source  packets.  Each  packet  consists  of  a  48-bit  header  and  variable  length  data 
field.  A  source  packet  must  consist  of  at  least  seven,  and  no  more  than  65,542,  bytes. 
Source  packets  may  be  fixed  or  variable  length  during  a  mission  [4,  5].  The  following 
source  packet  payload  lengths  (in  bytes)  will  be  tested:  5,  194,  500,  2000,  20000,  and 
60000.  These  values  were  chosen  to  cover  the  spectrum  of  possible  lengths.  The  194- 
byte  data  point  was  chosen  so  that  one  source  packet  would  exactly  fit  into  one  200-byte 
transfer  frame  payload.  These  test  cases  produced  enough  sample  points  to  get  an  initial 
view  of  how  source  packet  length  affects  throughput  and  data  quality.  Once  the 
experiments  were  underway,  source  packet  length  was  more  precisely  set  based  on  the 
preliminary  performance  results. 

Transfer  Frame  Length:  Source  packets  are  multiplexed  together  into  a  synchronous 
stream  of  fixed- length  transfer  frames  for  transmission  to  the  ground.  Frame  length  is 
constant  throughout  a  specific  mission  phase  and  is  limited  to  1115  bytes.  For  this 
investigation,  two  configurations  of  the  transfer  frame  header  were  used.  When  Reed- 
Solomon  encoding  was  used,  the  transfer  frame  header  consisted  of  only  the  6-byte 
primary  header.  In  this  case,  an  additional  160  bytes  (Reed- Solomon  check  symbols) 
was  appended  to  the  transfer  frame.  When  Reed- Solomon  encoding  was  not  used,  an  8- 
byte  transfer  frame  header  was  used  (6-byte  primary  header  plus  2-byte  frame  error 
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control  field).  Regardless  of  transfer  frame  length,  a  4-byte  synchronization  pattern  was 
appended  to  the  beginning  of  the  transfer  frame.  This  synchronization  marker  was  used 
by  the  receiving  network  to  acquire  synchronization  with  the  frame  boundaries  after 
transmission  through  the  data  channel.  The  two  transmission  configurations  used  are: 


•  No  Reed-Solomon: 


synchronization  +  transfer  frame 

v _ _ _ J  v _ _ _ J 

V  V 

4  bytes  8-byte  header  +  up  to  1 107  bytes  of  data 


•  With  Reed-Solomon: 


synchronization 
v _ J 


+  transfer  frame 
v _ J 


+ 


- V  V" 

4  bytes  6-byte  header  +  up  to  1 109  bytes  of  data 


R-S  check  symbols 
V  v  7 
160  bytes 


The  following  transfer  frame  payload  lengths  (in  bytes)  were  tested:  41,  200,  400, 
600,  800,  and  1000.  These  values  were  chosen  to  cover  the  spectrum  of  possible  transfer 
frame  payload  lengths.  The  payload  length  of  41  bytes  was  chosen  so  that  the  total 
transmitted  block  of  53  bytes  (data  +  6-byte  transfer  frame  header  +  2  CRC  bytes  +  4 
synchronization  bytes)  would  mirror  a  53-byte  ATM  cell.  This  was  done  to  aid  in  the 
application  of  these  research  results  to  an  ATM-based  packet  telemetry  scheme.6  These 
test  cases  produced  enough  sample  points  to  get  an  initial  view  of  how  transfer  frame 

6  This  'ATM  test  case'  does  not  apply  when  Reed-Solomon  encoding  is  used  because  the  minimum  number 
of  bytes  in  a  transmitted  block  is  171  (4  sync  bytes  +  7  byte  transfer  frame  +  160  bytes  R-S  check 
symbols). 
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length  affects  throughput  and  reliability.  Once  the  experiments  were  underway,  transfer 
frame  length  was  more  precisely  set  based  on  the  preliminary  performance  results. 

3.2.4  Performance  Metrics.  The  performance  metrics  used  in  this 
investigation  are  defined  as  follows: 

Effective  Data  Throughput :  The  average  number  of  data  bytes  successfully  received  by 
the  ground  node  per  unit  time,  in  bytes  per  second.  A  byte  was  considered  successfully 
received  if  it  was  part  of  a  transfer  frame  that  was  successfully  received.  A  transfer 
frame  was  successfully  received  if  the  number  of  bytes  in  error  was  within  allowable 
tolerances.  The  error  tolerances  depended  on  whether  Reed-Solomon  encoding  was 
being  used  or  not.  If  Reed-Solomon  encoding  was  not  used,  a  transfer  frame  was 
considered  successfully  received  if  no  byte  errors  were  detected  by  the  frame-error 
control  bytes.  Effective  data  throughput  was  computed  by  dividing  the  number  of  data 
bytes  received  by  the  time  (in  seconds)  it  took  to  transmit  the  data  bytes  plus  the 
associated  overhead. 

Data  Quality:  The  percentage  of  successfully  received  source  packets  at  the  ground  node. 
This  statistic  was  expressed  as  a  percentage,  with  100  indicating  error- free  data 
transmission.  This  metric  was  computed  by  dividing  the  number  of  source  packets 
successfully  received  at  the  ground  node  by  the  total  number  of  source  packets 
transmitted. 
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Channel  Utilization:  A  measure  of  the  consumption  of  the  available  RF  channel 
bandwidth.  It  measured  the  proportion  of  the  transmitted  data  stream  containing  actual 
telemetry  information  (data  +  overhead),  versus  "idle"  data  used  to  complete  an  unfilled 
transfer  frame.  This  statistic  was  expressed  as  a  percentage,  with  100  indicating  full 
usage.  The  source  packet  generation  rate  was  set  in  each  case  to  achieve  near- 100% 
channel  utilization.  This  parameter  was  measured  for  the  purpose  of  model  verification 
and  not  to  optimize  CCSDS  performance. 

Data  Latency:  The  period  between  when  the  source  packet  was  generated  and  when  it 
was  received  in  its  entirety  on  the  ground,  measured  in  seconds.  This  metric  was  not 
used  to  optimize  CCSDS  performance,  instead  it  was  observed  during  each  simulation 
run  for  the  purposes  of  model  verification. 

3.2.5  Protocol  Optimization.  The  results  of  the  simulations  were  evaluated  in 
three  ways:  for  maximum  throughput  (e.g.,  for  "video  data"),  maximum  data  quality 
(e.g.,  for  "memory  data"),  and  to  achieve  the  best  tradeoff  between  throughput  and  data 
quality  (e.g.,  for  missions  involving  both  "video"  and  "memory"  data).  The  results  of  the 
study  will  allow  a  test  designer  to  make  the  following  pre- mission  decisions: 

•  Based  on  the  type  of  data  to  be  transmitted,  what  combination  of  source 
packet  length,  transfer  frame  length,  and  Reed- Solomon  encoding  will 
maximize  effective  throughput? 
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•  Based  on  the  type  of  data  to  be  transmitted,  what  combination  of  source 
packet  length,  transfer  frame  length,  and  Reed- Solomon  encoding  will 
maximize  the  reliability  of  the  received  data? 

•  Based  on  the  type  of  data  to  be  transmitted,  what  combination  of  source 
packet  length,  transfer  frame  length,  and  Reed- Solomon  encoding  will  give 
the  best  tradeoff  between  effective  throughput  and  data  quality? 


Table  1  lists  the  experimental  factors  that  were  varied  in  the  course  of  the  study. 
Each  factor  could  take  on  a  finite  set  of  values,  referred  to  as  levels. 


Table  1.  Experimental  Factors 


Factor 

#  of  Levels 

Levels 

Source  Packet  Length 

6 

5,  194,  500,  2000,  20000,  60000  bytes 

Transfer  Frame  Length 

6 

41,  200,  400,  600,  800,  1000  bytes 

Error  Correction 

2 

R-S  or  no  R-S 

The  number  of  experiments  required  for  a  full  factorial  evaluation  was  6x6x2  = 

72.  These  were  used  for  the  initial  study  (with  five  replications).  After  the  preliminary 
trends  were  discovered,  the  experiments  were  more  finely  focused  to  key  in  on  areas  of 
interest  and  usefulness.  Table  2  summarizes  the  experiment  schedule.  After  the  initial  72 
simulation  runs,  certain  ranges  of  transfer  frame  and  source  packet  lengths  were  "zoomed 
in"  upon  to  increase  the  precision  with  which  values  were  chosen  to  maximize  throughput 
and/or  data  quality. 

The  final  data  run  in  the  initial  set,  number  73,  was  added  to  compare  the 
performance  of  the  CCSDS  and  ATM  protocols.  Given  the  individual  header/overhead 
requirements  of  the  ATM  and  CCSDS  protocols,  it  was  not  possible  to  configure  a 
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CCSDS  transfer  frame,  and/or  source  packet,  to  have  48  bytes  of  useful  data  and  five 
bytes  of  overhead  as  exists  in  an  ATM  cell.  With  this  "simple"  solution  not  available,  the 
next  best  solution  was  to  conduct  the  ATM/CCSDS  performance  comparison  using  a 
CCSDS  transfer  frame-source  packet  combination  of  the  same  data- to- overhead  ratio  as 
an  ATM  cell,  namely  48:5.  The  result  was  a  transfer  frame  payload  length  of  179  bytes 
and  a  source  packet  payload  length  of  173  bytes.  Derivation  of  these  values  is  shown  in 
Appendix  C. 

3.3  Determining  Simulation  Length  &  Sample  Size 

Using  a  typical  T-39  mission  length  of  three  hours,  each  of  the  73  simulations 
could  have  been  run  for  up  to  three  hours,  in  simulation  time  (vice  wall  clock),  and  the 
resulting  performance  data  (e.g.,  throughput  and  data  quality)  collected.  This  approach, 
however,  would  needlessly  waste  time  and  resources  since  the  same  performance 
information  could  be  attained  in  less  than  three  hours.  The  simulation  length  used  was 
based  on  the  desired  level  of  accuracy  and  confidence.  Based  on  the  notion  that  this 
batch  of  simulations  was  only  the  first  wide- sweeping  look  at  where  maximum 
performance  might  occur,  a  desired  accuracy  of  90%  and  a  confidence  level  of  80%  were 
chosen.  Simulation  length  calculations  are  shown  in  Appendix  E.  Each  simulation  was 
executed  five  times,  using  different  random  number  generator  seeds.  This  sample  size 
resulted  in  a  worst- case  confidence  level  of  90%.  Throughput  data  from  these 
simulations  is  accurate  within  ±180  Bps,  and  data  quality  data  is  accurate  within  ±0.15 
percentage  points.  Confidence  and  accuracy  calculations  are  shown  in  Appendix  E. 
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Table  2.  Experiment  Descriptions 


Run 

TF  Len 

(bytes) 

SP  Len 

(bytes) 

RS 

SP  Data 
Rate  (Bps) 

37 

41 

7 

Y 

60160 

38 

41 

200 

Y 

61425 

39 

41 

500 

Y 

61620 

40 

41 

2000 

Y 

61715 

41 

41 

20000 

Y 

61745 

42 

41 

60000 

Y 

61745 

43 

200 

7 

Y 

102380 

44 

200 

200 

Y 

102380 

45 

200 

500 

Y 

103000 

46 

200 

2000 

Y 

103210 

47 

200 

20000 

Y 

103300 

48 

200 

60000 

Y 

103300 

49 

400 

7 

Y 

105000 

50 

400 

200 

Y 

105000 

51 

400 

500 

Y 

105240 

52 

400 

2000 

Y 

105390 

53 

400 

20000 

Y 

105480 

54 

400 

60000 

Y 

105480 

55 

600 

7 

Y 

105900 

56 

600 

200 

Y 

105900 

57 

600 

500 

Y 

105900 

58 

600 

2000 

Y 

106150 

59 

600 

20000 

Y 

106220 

60 

600 

60000 

Y 

106230 

61 

800 

7 

Y 

106360 

62 

800 

200 

Y 

106360 

63 

800 

500 

Y 

106360 

64 

800 

2000 

Y 

106530 

65 

800 

20000 

Y 

106600 

66 

800 

60000 

Y 

106610 

67 

1000 

7 

Y 

106640 

68 

1000 

200 

Y 

106640 

69 

1000 

500 

Y 

106640 

70 

1000 

2000 

Y 

106740 

71 

1000 

20000 

Y 

106830 

72 

1000 

60000 

Y 

106830 

73 

179 

173 

N 

1 15820 

Run 

TF  Len 

(bytes) 

SP  Len 

(bytes) 

RS 

SP  Data  Rate 

(Bps) 

1 

41 

7 

N 

92865 

2 

41 

200 

N 

95910 

3 

41 

500 

N 

96390 

4 

41 

2000 

N 

96620 

5 

41 

20000 

N 

96690 

6 

41 

60000 

N 

96700 

7 

200 

7 

N 

116720 

8 

200 

200 

N 

116720 

9 

200 

500 

N 

1 17520 

10 

200 

2000 

N 

1 17800 

1 1 

200 

20000 

N 

1  17910 

12 

200 

60000 

N 

1  17920 

13 

400 

7 

N 

120720 

14 

400 

200 

N 

120720 

15 

400 

500 

N 

121040 

16 

400 

2000 

N 

121230 

17 

400 

20000 

N 

121350 

18 

400 

60000 

N 

121350 

19 

600 

7 

N 

122110 

20 

600 

200 

N 

1221  10 

21 

600 

500 

N 

1221  10 

22 

600 

2000 

N 

122440 

23 

600 

20000 

N 

122540 

24 

600 

60000 

N 

122540 

25 

800 

7 

N 

122820 

26 

800 

200 

N 

122820 

27 

800 

500 

N 

122820 

28 

800 

2000 

N 

123040 

29 

800 

20000 

N 

123140 

30 

800 

60000 

N 

123150 

31 

1000 

7 

N 

123250 

32 

1000 

200 

N 

123250 

33 

1000 

500 

N 

123250 

34 

1000 

2000 

N 

123380 

35 

1000 

20000 

N 

123500 

36 

1000 

60000 

N 

123510 

TF  Len  =  transfer  frame  payload  length  in  bytes;  SP  Len  =  source  packet  payload  length  in  bytes;  RS 
=  Reed-Solomon  (N  =  off,  Y  =  on);  SP  Data  Rate  =  source  packet  generation  rate  in  bytes  per  second 
(based  on  100%  channel  utilization) 
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During  the  effort  to  determine  a  suitable  simulation  length,  it  became  clear  that  no 
one  length  would  satisfy  the  accuracy  and  confidence  level  requirements  in  all  73  cases. 
As  a  result,  simulation  length  calculations  were  performed  for  all  73  cases.  There  were 
distinct  groupings  among  the  simulation  lengths  calculated,  falling  out  primarily  by 
source  packet  length.  To  simplify  execution  of  the  simulations,  four  simulation  lengths 
were  chosen  according  to  these  groupings.  The  simulation  schedule  is  repeated  in  Table 
3  with  the  simulation  length  for  each  case  shown.  Each  simulation  was  run  for  the 
simulation  length  that  achieved  the  desired  accuracy  and  confidence  level  or  for  three 
hours,  whichever  number  was  smaller.  In  all  cases,  the  channel  error  characteristics  were 
the  same,  namely  88%  of  the  time  the  channel  was  "error  free",  10%  of  the  time  the 
channel  experienced  "cluster"  errors,  and  2%  of  the  time  it  experienced  "burst"  errors. 

3.4  Channel  Characterization 

To  emulate  the  bursty-error  behavior  of  the  downlink  channel,  a  custom-designed 
link  model  was  used  (Appendix  A  contains  a  complete  description).  Numerous  efforts 
have  been  made  to  measure  bit  error  performance  of  aeronautical  telemetry  links  [18]. 
Fusing  channel  characterization  results  and  demodulated  bit  error  probability  (BEP)  files 
into  systematic  conclusions  is  highly  problematic  since  there  is  no  single  air-to-ground 
channel  scenario.  Flight  profile,  vehicle  speed  ranges,  antenna  type  and  placement,  and 
local  terrain  are  all  uncontrolled  variables  that  significantly  influence  channel 
characteristics. 
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Table  3.  Experiment  Schedule  Including  Simulation  Length 


R 

u 

n 

TF  Len 
(bytes) 

SP  Len 
(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Length 

(sec) 

R 

u 

n 

TF  Len 

(bytes) 

SP  Len 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Length 

(sec) 

i 

41 

7 

N 

92865 

35 

41 

7 

E9 

60160 

35 

B 

41 

200 

N 

95910 

35 

41 

200 

D 

61425 

35 

B 

41 

500 

N 

96390 

35 

41 

500 

mm 

61620 

35 

B 

41 

2000 

N 

96620 

35 

41 

2000 

mm 

61715 

35 

B 

41 

20000 

N 

96690 

10800 

EEB 

41 

20000 

mm 

61745 

10800 

rr 

41 

60000 

N 

96700 

10800 

41 

60000 

mm 

61745 

10800 

B 

200 

7 

N 

116720 

35 

200 

7 

mm 

102380 

35 

rr 

200 

200 

N 

116720 

35 

200 

200 

mm 

102380 

35 

B 

200 

500 

N 

117520 

35 

m 

200 

500 

mm 

103000 

35 

m 

200 

2000 

N 

117800 

35 

200 

2000 

mm 

103210 

35 

m 

200 

20000 

N 

117910 

3300 

200 

20000 

mm 

103300 

3300 

m 

200 

60000 

N 

117920 

3300 

200 

60000 

mm 

103300 

3300 

m 

400 

7 

N 

120720 

35 

400 

7 

mm 

105000 

35 

m 

400 

200 

N 

120720 

35 

ETil 

400 

200 

mm 

105000 

35 

m 

400 

500 

N 

121040 

35 

m 

400 

500 

mm 

105240 

35 

B 

400 

2000 

N 

121230 

35 

m 

400 

2000 

wm 

105390 

35 

m 

400 

20000 

N 

121350 

3300 

in 

400 

20000 

mm 

105480 

3300 

m 

400 

60000 

N 

121350 

3300 

m 

400 

60000 

mm 

105480 

3300 

m 

600 

7 

N 

122110 

35 

600 

7 

mm 

105900 

35 

ESI 

600 

200 

N 

122110 

35 

600 

200 

mm 

105900 

35 

m 

600 

500 

N 

122110 

35 

m 

600 

500 

mm 

105900 

35 

600 

2000 

N 

122440 

35 

ESI 

600 

2000 

mm 

106150 

35 

600 

20000 

N 

122540 

3300 

m 

600 

20000 

mm 

106220 

3300 

600 

60000 

N 

122540 

3300 

m 

600 

60000 

mm 

106230 

3300 

m 

800 

7 

N 

122820 

35 

m 

800 

7 

mm 

106360 

35 

800 

200 

N 

122820 

35 

m 

800 

200 

mm 

106360 

35 

800 

500 

N 

122820 

35 

m 

800 

500 

mm 

106360 

35  ! 

800 

2000 

N 

123040 

35 

m 

800 

2000 

m 

106530 

35 

800 

20000 

N 

123140 

3300 

m 

800 

20000 

mm 

106600 

3300 

nil 

800 

60000 

N 

123150 

3300 

m. 

800 

60000 

wm 

106610 

3300 

m 

1000 

7 

N 

123250 

35 

m 

1000 

7 

mm 

106640 

35 

1000 

200 

N 

123250 

35 

m 

1000 

200 

106640 

35 

1000 

500 

N 

123250 

35 

m 

1000 

500 

mm 

106640 

35 

1000 

2000 

N 

123380 

35 

HI 

1000 

2000 

mm 

106740 

35 

1000 

20000 

N 

123500 

750 

HI 

1000 

20000 

mm 

106830 

750 

1000 

60000 

N 

1235  10 

750 

1000 

60000 

m 

106830 

750 

179 

173 

N 

115820 

35 

TF  Len  =  transfer  frame  payload  length  in  bytes;  SP  Len  =  source  packet  payload  length  in  bytes;  RS 
=  Reed-Solomon  (N  =  off,  Y  =  on);  SP  Data  Rate  =  source  packet  generation  rate  in  bytes  per  second 
(based  on  100%  channel  utilization) 


Despite  these  difficulties,  flight  tests  conducted  by  the  ARTM  project  office 


have  confirmed  the  two  primary  sources  of  bit  errors  and  short-term  failure  links  in  the 
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n 

traditional  test  corridors  at  Edwards  AFB  are  "error  bursts"  and  "error  clusters".  An 
error  burst  is  a  sporadic,  impulse-type  event,  where  the  BEP  suddenly  degrades  to  the 
range  of  10"“  to  10"  .  The  duration  of  error  bursts  (at  T-39  speeds  over  the  baseline 
corridors)  is  in  the  range  of  a  few  hundred  milliseconds  (msec)  to  one  second.  The 
second  type  of  error,  an  error  cluster,  occurs  more  frequently  and  is  associated  with 
strong,  two-ray,  frequency  selective  fades.  They  are  primarily  seen  when  the  receiving 
antenna  main  lobe  grazes  the  ground  or  horizon.  BEP  values  during  an  error  cluster  are 
approximately  0.5.  Actually,  the  receiver/detector  has  lost  synchronization- -the  link  is 
broken.  The  link  model  used  in  the  OPNET  design  was  built  to  emulate  the  real-world 
channel  behavior  as  closely  as  possible. 

From  ARTM's  work  to  characterize  the  telemetry  link  it  is  known  that  two  types 
of  errors  can  occur  -  error  clusters  and  error  bursts.  Although  it  is  difficult  to  precisely 
quantify  the  channel  behavior,  for  the  purposes  of  this  research  only  an  approximate  level 
of  accuracy  was  required.  Table  4  summarizes  the  channel  profile  that  was  used.  These 
values  are  based  on  "typical"  results  from  ARTM  flight  tests. 


Table  4.  Channel  Profile 


State 

Percentage  of  time  spent  in  state  (%) 

BEP 

Duration  (msec) 

Error- free 

88 

0 

variable 

Error-cluster 

10 

0.5 

100-1000 

Error-burst 

2 

200 

7  The  ARTM  project  used  four  of  the  traditional  test  corridors  at  Edwards  AFB,  however  the  most  useful 
(repeatable)  baseline  link  performance  data  was  obtained  from  three--"CORDs  Road",  "Black  Mountain”, 
and  one  of  the  high  altitude  supersonic  corridors. 
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3.5  Model  Validation 


The  purpose  of  validating  the  model  is  to  ensure  the  assumptions  used  in 
developing  it,  the  input  parameter  values  and  distributions,  and  the  output  values  and 
conclusions  are  reasonable  in  that  the  results  are  close  to  that  observed  in  real  systems 
[12].  The  assumptions  made  in  constructing  this  model  (e.g.,  errors  due  to  environmental 
variables,  such  as  weather  and  flight  altitude,  can  be  lumped  into  channel  BER)  were 
validated  by  expert  intuition,  namely  members  of  the  ARTM  project  office.  The  input 
parameter  values  and  error  distributions  (i.e.,  channel  characterization)  used 
representative  real-world  results  from  previous  flight  tests  at  Edwards  AFB.  The  output 
values  and  conclusions  of  this  investigation  were  validated  by  flight  test  in  October  2001 
as  part  of  the  USAF  TPS  curriculum. 


3.6  Model  Verification 

In  simple  terms,  the  purpose  of  verifying  the  model  is  to  ensure  it  does  what  it  is 
intended  to  do.  This  can  also  be  referred  to  as  debugging.  This  was  done  by  building  the 
model  in  a  modular  fashion  and  running  progressively  more  complex  simulations.  For 
example: 

•  constant  input  stream  with  error- free  channel 

•  constant  input  stream  with  constant  channel  error-rate 

•  constant  input  stream  with  realistic  channel  error 
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In  addition,  other  debugging- type  checks  were  made,  such  as  ensuring  the  number 
of  bytes  generated  by  the  data  sources  equals  the  number  of  bytes  received  at  the  ground- 
node  and  monitoring  data  latency  of  the  source  packets  for  any  anomalies. 

3. 7  Summary 

This  chapter  has  detailed  the  methodology  to  be  used  in  evaluating  the  CCSDS 
protocol  in  the  test  range  environment.  While  some  simplifying  assumptions  were  made, 
the  overall  channel  BER  should  incorporate  the  combined  errors  due  to  the  environmental 
variables  removed  by  the  assumptions.  A  complete  description  of  the  OPNET  model  is 
given  in  Appendices  A  and  B.  For  a  full  factorial  experiment,  72  initial  test  cases  were 
run,  plus  one  test  case  to  compare  the  performance  of  the  CCSDS  and  ATM  protocols. 
Once  the  model  was  verified  and  the  data  collected,  the  results  were  validated  via  flight 
test  as  part  of  the  USAF  Test  Pilot  School  curriculum.  Now  that  the  background  and 
methodology  have  been  established,  Chapter  IV  explores  and  compares  the  results  of  the 
protocol's  performance.  Flight  test  results  are  discussed  later,  in  Chapter  VI. 
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CHAPTER  IV  -  EXPERIMENTAL  RESULTS 


4.1  Introduction 

Chapter  III  described  the  methodology  used  to  evaluate  the  CCSDS  protocol. 

This  chapter  presents  the  results  of  applying  that  methodology.  It  begins  by  describing 
the  initial  and  secondary  sets  of  transfer  frame/source  packet/Reed- Solomon 
configurations  executed  in  the  OPNET  simulation.  Next,  it  discusses  the  effects  of  the 
various  CCSDS  parameters  on  throughput  and  data  quality  and  uses  that  knowledge  to 
determine  the  configurations  that  will  maximize  these  two  measures  of  performance.  The 
results  of  this  analysis  are  used  to  find  the  configuration  of  parameters  yielding  the  best 
compromise  between  throughput  and  data  quality.  Finally,  the  performance  of  the 
CCSDS  protocol  configured  to  emulate  the  data- to- overhead  ratio  of  the  basic  ATM 
protocol  is  compared  and  analyzed.  This  chapter  presents  selected  data  and  hand-drawn 
curves  to  illustrate  trends  in  the  tested  parameters.  The  raw  experimental  data  in  its 
entirety  can  be  found  in  Appendix  E. 

4.2  Initial  &  Secondary  Data  Sets 

The  73  experimental  factor  combinations  described  in  Chapter  III  were  executed 
using  the  OPNET  model  designed  to  replicate  the  downlink  of  telemetry  data  at  Edwards 
AFB.  For  each  configuration  the  following  data  was  collected:  total  transmission  time, 
number  of  source  packets  transmitted,  number  of  source  packets  received  (intact  and 
within  error  tolerances),  number  of  idle  source  packets  transmitted,  and  end-to-end  delay 
for  each  source  packet.  From  these  values  the  following  performance  metrics  were 


42 


calculated  and/or  reported:  effective  data  throughput,  data  quality,  and  channel 
utilization.  Although  the  source  packet  generation  rate  was  set  in  each  case  to  achieve 
near- 100%  channel  utilization,  this  parameter  was  measured  for  the  purpose  of  model 
verification  (and  for  the  sanity  of  the  test  conductor). 

After  completion  of  the  initial  data  set,  additional  configurations  were  run  through 
the  simulator  to  fill  in  gaps  and/or  increase  the  resolution  of  the  initial  set  of  results.  This 
secondary  data  set  is  shown  in  Table  5  below.  The  results  of  the  secondary  data  set  were 
used  primarily  to  further  illustrate  the  effects  of  source  packet  length  on  data  quality  and 
to  more  precisely  pinpoint  peaks  in  the  data  quality  curves.  This  is  described  further  in 
Section  4.4.  In  all  cases,  five  replications  were  used,  with  different  random  number 
generator  seeds,  and  the  results  averaged.  Variances  were  too  small  to  display. 

4.3  Analysis  of  Effective  Data  Throughput  Results 

In  an  attempt  to  systematically  evaluate  the  effects  of  the  CCSDS  parameters  on 
data  throughput,  the  simulation  results  were  first  examined  with  Reed- Solomon  encoding 
turned  OFF.  As  shown  in  Figure  8,  effective  throughput  was  dependent  on  transfer 
frame  length.  In  general,  throughput  increased  as  transfer  frame  length  increased.  In  all 
cases,  a  transfer  frame  payload  length  of  1000  bytes  produced  the  highest  throughput. 

The  maximum  throughput  (with  Reed-Solomon  encoding  OFF)  was  108,360  Bps, 
occurring  with  a  transfer  frame  length  of  1000  bytes  and  source  packet  length  of  1000 
bytes.  Beyond  a  transfer  frame  payload  length  of  800  bytes  the  increase  in  throughput 
was  small,  ranging  from  only  0.09%  boosted  performance  (with  SP  =  5  bytes)  to  0.48% 
(with  SP  =  60,000  bytes).  Therefore,  if  transfer  frame  length  were  constrained  for  other 
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reasons,  a  payload  length  of  800  bytes  would  still  provide  near- maximum  throughput 


Table  5.  Secondary  Data  Set  to  Further  Explore  Data  Quality 
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performance.  Going  one  step  further,  a  transfer  frame  payload  length  of  600  bytes 
degraded  throughput  performance  by  less  than  0.75%  for  all  source  packet  payload 
lengths.  Stated  simply,  these  results  suggest  that  while  a  transfer  frame  payload  length  of 
1000  bytes  should  produce  the  highest  throughput  performance,  if  other  constraints  limit 
transfer  frame  payload  length,  the  user  should  still  get  within  0.75%  of  maximum 
throughput  performance  with  transfer  frame  payload  lengths  as  low  as  600  bytes.  (Note: 
For  a  transfer  frame  payload  length  of  400  bytes,  throughput  was  degraded  up  to  2.01%, 
and  up  to  4.7%  for  a  payload  length  of  200  bytes.) 


Transfer  Frame  Payload  Length  (bytes) 


Source  Packet 
Payload  Length 

■  1 94  bytes  (No  RS) 

A  1 000  bytes  (No  RS) 
•  60000  bytes  (No  RS) 


Figure  8.  Throughput  Performance  Variation  with  Transfer  Frame  Payload  Length 

(Trendlines  shown  are  hand-drawn) 


Figure  9  shows  that  effective  data  throughput  also  varied  with  source  packet 
length.  For  the  most  part,  throughput  performance  was  the  highest  for  source  packet 
payload  lengths  between  500  and  2000  bytes,  and  fell  off  for  payload  lengths  below  500 


45 


bytes  and  above  2000  bytes.  A  source  packet  length  of  1000  bytes  consistently  yielded 
the  highest  throughput.  The  percentage  difference  in  throughput  for  source  packet 
payload  lengths  between  500  and  2000  bytes,  however,  was  very  small.  The  difference 
in  throughput  was  at  worst  0.38%,  and  on  average  the  difference  was  only  0.12%.  With  a 
variation  this  small,  the  benefit  gained  in  finding  a  precise  peak  is  most  likely  not  worth 
the  time  and  resources  to  find  it.  These  results  suggest  that  to  maximize  throughput 
performance  source  packet  payload  length  should  be  set  to  1000  bytes;  however  given 
other  constraints,  a  source  packet  payload  length  between  500  and  2000  bytes  will  also 
yield  top  throughput  performance. 


Source  Packet  Payload  Length  -  Log  Scale  (bytes) 


Transfer  Frame 
Payload  Length 

B  200  bytes  (No  RS) 
A  400  bytes  (No  RS) 

•  1 000  bytes  (No  RS) 


Figure  9.  Throughput  Performance  Variation  with  Source  Packet  Payload  Length 

(Trendlines  shown  are  hand-drawn) 

The  effects  of  adding  Reed- Solomon  encoding  are  shown  in  Figure  10  through 
Figure  13.  In  general,  when  Reed-Solomon  encoding  was  turned  ON,  the  overall  trends 
were  similar  to  the  Reed-Solomon  OFF  cases,  however,  throughput  performance  was 
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lower.  The  best  throughput  attained  with  Reed-Solomon  ON  was  95,542  Bps,  occurring 
at  a  transfer  frame  payload  length  of  1000  bytes  and  source  packet  payload  length  of 
2000  bytes. 

With  regards  to  transfer  frame  length  (Figure  10),  throughput  with  Reed-Solomon 
ON  increased  as  transfer  frame  length  increased,  with  a  payload  length  of  1000  bytes  still 
producing  the  highest  throughput.  In  all  but  one  case  (TF  =  41  bytes),  better  throughput 
performance  was  attained  with  Reed-Solomon  encoding  turned  OFF.  As  shown  in  Figure 

11,  the  best  throughput  achieved  with  Reed-Solomon  encoding  OFF  was  12%  higher  than 
the  best  case  with  Reed-Solomon  encoding  ON. 

Similar  results  occurred  with  regards  to  source  packet  length.  As  shown  in  Figure 

12,  the  throughput  versus  source  packet  length  curve  had  the  same  basic  shape  as  the 
Reed-Solomon  OFF  case,  with  the  highest  throughput  occurring  for  the  range  of  source 
packet  payload  lengths  of  500  -  2000  bytes.  One  difference  between  this  and  the  Reed- 
Solomon  OFF  case  was  that  a  source  packet  payload  length  of  1400  bytes  generally 
produced  the  highest  throughput,  versus  1000  bytes  in  the  Reed-Solomon  OFF  case.  In 
all  but  one  case  (TF  =  41  bytes)  better  throughput  performance  was  attained  with  Reed- 
Solomon  encoding  turned  OFF.  And  again,  as  shown  in  Figure  13,  the  best  throughput 
achieved  with  Reed-Solomon  encoding  OFF  was  12%  higher  than  the  best  case  with 
Reed-Solomon  encoding  ON. 

Although  throughput  performance  with  Reed-Solomon  encoding  turned  ON  was 
higher  for  the  single  case  of  TF  =  41,  this  transfer  frame  length  in  general  produced  the 
lowest  throughput  of  all  possible  transfer  frame  lengths  with  both  Reed-Solomon  ON  and 
OFF,  and  would  therefore  not  be  chosen  as  a  possible  solution.  These  results  therefore 
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suggest  that  given  similar  channel  error  characteristics,  to  achieve  maximum  throughput 


performance,  Reed-Solomon  encoding  should  be  OFF. 
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Figure  10.  Effect  of  Reed-Solomon  Encoding  on  Throughput  (via  Transfer  Frame  Length) 

(Trendlines  shown  are  hand-drawn) 


Source  Packet 
Payload  Length 

♦  1000  bytes  (No  RS) 
■  1400  bytes  (RS) 


Figure  11.  Comparison  of  Throughput  With/Without  Reed-Solomon  Encoding  -  1 

(Trendlines  shown  are  hand-drawn) 
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Throughput  (bytes  per  second) 


Source  Packet  Payload  Length  -  Log  Scale  (bytes) 


Transfer  Frame 
Payload  Length 
«  200  bytes  (No  RS) 
•  1 000  bytes  (No  RS) 
X  400  bytes  (RS) 

°  800  bytes  (RS) 

A  1000  bytes  (RS) 


Figure  12.  Effect  of  Reed-Solomon  Encoding  on  Throughput  (via  Source  Packet  Length) 

(Trendlines  shown  are  hand-drawn) 


Figure  13.  Comparison  of  Throughput  With/Without  Reed-Solomon  Encoding  -  2 

(Trendlines  shown  are  hand-drawn) 
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Figure  14  is  a  contour  plot  of  the  simulation  data.  Only  the  Reed- Solomon  OFF 
results  are  plotted.  The  plot  supports  the  previous  conclusions.  In  the  plot,  the  region  of 
highest  throughput  occurs  for  transfer  frame  payload  lengths  from  approximately  600  to 
1000  bytes,  with  throughput  increasing  as  transfer  frame  payload  lengths  approach  1000 
bytes.  Source  packet  payload  lengths  for  best  throughput  ranged  from  about  500  to  2000 
bytes  (27  to  33  on  the  log  scale).  This  plot  will  be  used  again  later  to  find  the  CCSDS 
configuration  that  yields  the  best  compromise  between  throughput  and  data  quality. 


Figure  14.  Contour  Plot  -  Throughput  Variation  With  CCSDS  Parameters 

ANOVA  analysis  on  the  collected  data  showed  that  transfer  frame  length 
contributed  36.4%  to  the  resulting  throughput,  source  packet  length  20.8%,  and  Reed- 
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Solomon  encoding  31.0%.  The  remaining  12%  was  due  primarily  to  the  interaction 
between  transfer  frame  length  and  Reed-Solomon  encoding.  The  complete  ANOVA 
table  is  provided  in  Appendix  F. 

The  results  of  the  modeling  and  simulation  suggest  the  following  conclusions 
with  regards  to  maximizing  effective  data  throughput: 

1.  Reed-Solomon  encoding  should  be  OFF  for  maximum  throughput  performance. 

2.  A  transfer  frame  payload  length  between  600  and  1000  bytes  should  be  used  to 
obtain  top  throughput  performance. 

3.  A  source  packet  payload  length  between  500  and  2000  bytes  should  be  used  to 
obtain  top  throughput  performance. 

4.  Ultimate  solution:  Barring  other  constraints,  a  transfer  frame  payload  length  of 
1000  bytes,  source  packet  payload  length  of  1000  bytes,  and  Reed-Solomon 
encoding  OFF  should  be  used  to  obtain  the  highest  effective  data  throughput. 

4.4  Analysis  of  Data  Quality  Results 

To  systematically  evaluate  the  effects  of  the  CCSDS  parameters  on  data  quality, 
the  simulation  results  were  first  examined  with  Reed-Solomon  encoding  turned  OFF. 
Figure  15  shows  the  effect  of  transfer  frame  payload  length  on  data  quality.  Overall, 
there  was  no  substantial  correlation  between  transfer  frame  length  and  the  resulting  data 
quality.  Variation  in  data  quality  over  each  data  set  ranged  only  from  0.004  to  0.51  and 
ANOVA  analysis  of  the  collected  data  indicated  that  transfer  frame  payload  length 
contributed  only  0.015%  to  the  resulting  data  quality.  These  statistics  corroborate  the 
straight-line  nature  of  the  data  plotted  in  Figure  15. 


51 


Source  Packet 
Payload  Length 


89 

88 

87 

86 

85 

84 

83 

82 

81 


A  A 

- A 

A 

- A - 

- A 

- 26 - 

X 

X 

- - - 

- * - 

• 

• 

W 

- • - 

_ • 

• 

200 

400 

600 

800 

1000 

12 

Transfer  Frame  Payload  Length  (Bytes) 


A  500  bytes  (No  RS) 

*  20000  bytes  (No  RS) 

•  60000  bytes  (No  RS) 


Figure  15.  Data  Quality  Variation  with  Transfer  Frame  Payload  Length 

(Trendlines  shown  are  hand-drawn) 


Figure  16  shows  the  effect  of  source  packet  length  on  data  quality.  To  get  a  better 
view  of  what  was  going  on,  the  TF  =  41  point  was  eliminated  and  the  plot  rescaled. 

Figure  17  shows  the  result.  Data  quality  was  the  highest  for  source  packet  lengths 
between  500  and  2000  bytes,  and  fell  off  for  source  packet  lengths  below  500  bytes  and 
above  2000  bytes.  The  highest  data  quality  was  consistently  achieved  with  a  source 
packet  length  of  1000  bytes.  The  maximum  data  quality  (with  Reed- Solomon  encoding 
OFF)  was  88.25%,  occurring  with  a  source  packet  length  of  1000  bytes  and  transfer 
frame  length  of  200  bytes.  The  variance  in  data  quality  over  the  range  of  500  to  2000 
bytes  was  very  small,  ranging  from  0.0046  to  0.033.  Therefore,  for  top  data  quality 
performance  these  results  suggest  a  source  packet  payload  length  between  500  and  2000 
bytes  should  be  chosen,  with  1000  bytes  being  optimum. 
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Data  Quality  (%)  Data  Quality  (%) 


Transfer  Frame 
Payload  Length 

♦  41  bytes  (No  RS) 

H  200  bytes  (No  RS) 
A  400  bytes  (No  RS) 
0  600  bytes  (No  RS) 

*  800  bytes  (No  RS) 
0  TF  =  1000  (No  RS) 


Figure  16.  Data  Quality  Variation  with  Source  Packet  Payload  Length  - 1 

(Trendlines  shown  are  hand-drawn) 


Transfer  Frame 
Payload  Length 

A  400  bytes  (No  RS) 
•  1000  bytes  (No  RS) 


Source  Packet  Payload  Length  -  Log  Scale  (bytes) 


Figure  17.  Data  Quality  Variation  with  Source  Packet  Payload  Length  -  2 

(Trendlines  shown  are  hand-drawn) 
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The  effects  of  adding  Reed- Solomon  encoding  are  shown  in  Figure  18  -  Figure 
20.  In  general,  data  quality  was  higher  with  Reed- Solomon  ON,  but  the  average  amount 
of  improvement  was  less  than  2%.  The  best  data  quality  achieved  with  Reed- Solomon 
ON  was  89.59%.  This  occurred  with  a  source  packet  payload  length  of  1400  bytes  and 
transfer  frame  payload  length  of  400  bytes. 

With  regards  to  transfer  frame  length,  there  was  again  very  little  correlation 
between  transfer  frame  length  and  data  quality.  Data  quality  was  consistently  higher  with 
Reed-Solomon  encoding  ON,  as  shown  in  Figure  18.  Although  higher,  the  improvement 
gained  using  Reed-Solomon  was  relatively  small.  As  shown  in  Figure  19,  the  best  data 
quality  achieved  with  Reed-Solomon  encoding  ON  was  only  1.52%  higher  than  the  best 
case  with  Reed-Solomon  encoding  OFF. 
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Figure  18.  Effects  of  Reed-Solomon  Encoding  on  Data  Quality  (via  Transfer  Frame  Length) 

(Trendlines  shown  are  hand-drawn) 
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Figure  19.  Comparison  of  Best  Data  Quality  With/Without  Reed-Solomon  Encoding 

(Trendlines  shown  are  hand-drawn) 


As  shown  in  Figure  20,  the  data  quality  versus  source  packet  length  curve  had  the 
same  basic  shape  as  the  Reed-Solomon  OFF  case,  with  the  highest  data  quality  occurring 
in  the  range  of  source  packet  payload  lengths  of  500  -  2000  bytes.  One  difference 
between  this  and  the  Reed-Solomon  OFF  case  was  that  a  source  packet  payload  length 
between  1400  -  2000  bytes  generally  produced  the  highest  throughput,  versus  1000  bytes 
in  the  Reed-Solomon  OFF  case.  This  plot  again  shows  that  although  data  quality  was 
higher  with  Reed-Solomon  ON,  the  improvement  was  less  than  2%. 

These  results  suggest  two  things.  First,  in  order  to  maximize  data  quality,  Reed- 
Solomon  encoding  should  be  ON.  Second,  given  that  the  improvement  in  data  quality 
was  relatively  small,  and  that  data  quality  will  inevitably  be  driven  by  the  channel  BER 
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as  witnessed  here  where  the  error- free  percentage  was  generally  88%  and  the  top  data 
quality  achieved  also  fell  in  the  vicinity  of  88%,  in  the  presence  of  other  constraints, 
near- top  data  quality  performance  is  achievable  with  Reed- Solomon  OFF. 


Figure  20.  Effects  of  Reed-Solomon  Encoding  on  Data  Quality  (via  Source  Packet  Length) 

(Trendlines  shown  are  hand-drawn) 


Figure  21  and  Figure  22  are  contour  plots  of  the  simulation  data  with  and  without 
Reed-Solomon  encoding,  respectively.  The  plot  supports  the  previous  conclusions.  The 
slopes  of  the  results  are  extremely  shallow  indicating  that  changing  transfer  frame  and 
source  packet  length  has  little  effect  on  data  quality.  In  the  plot,  the  region  of  highest 
data  quality  occurs  for  source  packet  payload  lengths  from  approximately  500  to  2000 
bytes  (27  to  33  on  the  log  scale),  with  data  quality  fairly  even  throughout  the  range.  This 
plot  will  be  used  again  later  to  find  the  CCSDS  configuration  that  yields  the  best 
compromise  between  throughput  and  data  quality. 
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Figure  21.  Contour  Plot  of  Data  Quality  Variation  With  Reed-Solomon  ON 


ANOVA  analysis  on  the  collected  data  showed  that  source  packet  length 
contributed  99.3%  to  the  resulting  data  quality,  transfer  frame  length  0.015%,  and  Reed- 
Solomon  encoding  0.15%.  The  remaining  0.5%  was  due  primarily  to  the  interactions 
between  transfer  frame  and  source  packet  length.  These  statistics  support  the  results 
discussed  in  this  section.  The  complete  ANOVA  table  is  provided  in  Appendix  F. 
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Contour  Plot  of  Data  Quality 


Legend  -  Data  Quality  (%) 


Figure  22.  Contour  Plot  of  Data  Quality  Variation  with  Reed-Solomon  OFF 


The  results  of  the  modeling  and  simulation  suggest  the  following  conclusions 
with  regards  to  maximizing  data  quality: 

1.  Transfer  frame  length  has  a  negligible  affect  on  the  resulting  data  quality. 

2.  Reed-Solomon  encoding  should  be  ON  for  maximum  data  quality. 

3.  Near-maximum  data  quality  (within  2%  of  maximum)  is  achievable  with 
Reed-Solomon  encoding  OFF. 

4.  A  source  packet  payload  length  between  500  and  2000  bytes  should  be  used  to 
obtain  top  data  quality  performance. 
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5.  Ultimate  Solution:  A  source  packet  payload  length  of  1400  bytes  with  Reed- 
Solomon  encoding  ON  should  be  used  to  obtain  the  highest  data  quality. 

6.  Runner-Up  Solution:  A  source  packet  payload  length  of  1000  bytes  with 
Reed-Solomon  encoding  OFF  can  be  used  to  obtain  top  data  quality  results. 

4.5  Best  Tradeoff  Between  Throughput  &  Data  Quality 

To  determine  the  CCSDS  configuration  that  would  offer  the  user  the  best 
compromise  between  throughput  and  data  quality  performance,  the  primary  assumption 
was  that  the  two  performance  requirements  were  equally  weighted  in  priority.  In  reality, 
this  may  not  always  be  the  case;  determining  the  best  configuration  for  varying  cases  of 
priority  is  left  to  future  study. 

To  aid  in  the  determination  of  a  "best  compromise"  CCSDS  configuration,  two 
methods  were  used.  The  first  method  was  to  take  the  two  contour  plots  used  to 
individually  evaluate  throughput  and  data  quality  and  overlay  them  to  qualitatively  find 
the  area(s)  where  both  performance  metrics  faired  particularly  well.  The  second  method 
used  the  statistical  software  Design  Expert  [8].  This  software,  which  was  also  used  to 
execute  the  ANOVA  analysis  on  the  data  in  previous  sections,  contained  a  function  for 
listing  the  data  points  (i.e.,  combination  of  CCSDS  parameters)  according  to  a  pre¬ 
defined  sorting  requirement,  for  example  "maximize  throughput",  "maximize  data 
quality",  or  "maximize  throughput  and  data  quality".  Using  this  last  option,  the  Design 
Expert  software  provided  its  solution  to  the  problem.  One  limitation  to  this  method  was 
that  the  software  would  only  choose  its  solution  from  among  the  data  points  in  the 
original  matrix  structure  of  possible  parameter  values  (i.e.,  source  packet  length  equals  5, 
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50,  100,  150,  194,  300,  500,  700,  1000,  1400,  2000,  6000,  20000,  or  60000  only).  In 


other  words,  it  was  not  able  to  interpolate  over  the  entire  range  of  possible  values  (i.e., 
source  packet  length  can  be  anywhere  between  5  and  60000)  and  choose  a  solution  that 
was  not  within  its  matrix  of  possible  parameter  configurations.  Nonetheless,  the  software 
was  used  to  provide  a  rough  verification  of  the  results  of  the  first  method.  Both  methods 
yielded  similar  results. 

4.5. 1  First  Method  -  Overlay  of  Contour  Plots 

Figure  23  and  Figure  24  show  an  overlay  of  the  contour  plots  used  to  analyze 
throughput  (Figure  14)  and  data  quality  (Figure  21  and  Figure  22).  Figure  23  is  with 
Reed-Solomon  ON,  Figure  24  with  it  OFF.  Examination  of  the  two  figures  shows  that 
the  greater  region  of  overlap  between  best  throughput  and  data  quality  occurs  when 
Reed-Solomon  is  OFF.  This  makes  sense  from  the  previous  analysis  of  throughput  and 
data  quality.  Although  Reed-Solomon  offered  a  slight  improvement  in  data  quality,  it 
severely  degraded  throughput  performance.  Therefore,  the  search  for  a  best  combined 
performance  solution  will  be  made  with  Reed-Solomon  encoding  OFF. 

Since  previous  analysis  indicated  that  data  quality  did  not  vary  significantly  with 
transfer  frame  length,  it  is  not  surprising  that  the  best  combined  performance  occurred  at 
the  same  transfer  frame  lengths  for  optimum  throughput  performanc  e,  namely  600  to 
1000  bytes.  This  was  true  regardless  of  whether  Reed-Solomon  was  used. 
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Contour  Plot  ofThroughput  and  Data  Quality 


Legend  Throughput  (bytes/sec) 

Data  Quality  (%) 


Figure  24.  Contour  Plot  of  Combined  Performance  With  Reed-Solomon  OFF 
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With  Reed- Solomon  OFF,  the  source  packet  payload  lengths  yielding  the  best 
combined  performance  were  approximately  500  to  2000  bytes.  The  reason  that  the 
source  packet  length  for  optimum  throughput  performance  matched  that  for  the  best 
combined  performance  is  less  obvious,  until  observing  the  contour  plot.  In  the  area 
corresponding  to  a  transfer  frame  payload  length  of  600-1000  bytes  and  source  packet 
payload  lengths  between  500-2000  bytes,  the  slope  of  data  quality  results  are  extremely 
shallow  when  compared  to  those  of  throughput  results.  This  indicates  that  changing 
source  packet  payload  length  from  500  bytes  to  2000  bytes  would  have  very  little  effect 
on  data  quality  but  could  noticeably  improve  throughput. 

In  summary,  these  results  suggest  that  to  achieve  the  best  combined  throughput 
and  data  quality,  transfer  frame  payload  length  should  be  between  600-1000  bytes,  source 
packet  payload  length  should  be  from  500-2000  bytes,  and  Reed- Solomon  encoding  OFF. 

4.5.2  Second  Method  -  Statistical  Software  Solution 

The  second  method  to  find  a  "best  compromise"  solution  used  the  statistical 
software  Design  Expert  [8].  When  attempting  to  maximize  both  throughput  and  data 
quality,  Design  Expert  offered  the  following  guidance:  transfer  frame  payload  length 
between  400  and  1000  bytes;  source  packet  payload  length  between  500  and  1400  bytes, 
and  Reed- Solomon  encoding  OFF.  In  general,  these  results  agreed  with  the  analysis  of 
the  contour  plots. 

Taking  the  most  conservative  of  the  solutions,  to  maximize  both  throughput  and 
data  quality,  the  results  of  both  the  contour  plot  analysis  and  Design  Expert  guidance 
suggest  that  transfer  frame  payload  length  should  be  between  500  to  1000  bytes,  with 
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1000  bytes  being  the  best.  Source  packet  payload  length  should  be  between  500  and 
1400  bytes,  with  1000  bytes  yielding  the  best  performance  in  the  Design  Expert  analysis, 
and  Reed- Solomon  encoding  should  be  OFF. 

4.6  ATM  y.s'  CCSDS  -  A  Performance  Comparison 

Table  6  shows  how  the  "ATM- version"  of  CCSDS  faired  in  comparison  to  the 
best  performance  of  the  unadulterated  CCSDS  protocol.  As  discussed  in  Chapter  III,  the 
CCSDS  configuration  used  in  the  "ATM- version"  was  a  transfer  frame  payload  length  of 
179  bytes,  a  source  packet  payload  length  of  173  bytes,  and  Reed-Solomon  encoding 
OFF.  Derivation  of  these  values  can  be  found  in  Appendix  D.  The  CCSDS 
configuration  used  for  the  comparison  was  a  transfer  frame  payload  length  of  1000  bytes, 
a  source  packet  payload  length  of  1000  bytes,  and  Reed-Solomon  encoding  OFF.  This 
configuration  was  chosen  because  it  produced  the  best  compromise  between  throughput 
and  data  quality  (see  Section  4.5).  It  should  be  noted  that  the  best  throughput  achieved 
overall  was  108,360  Bps  (see  Section  4.3),  and  best  data  quality  achieved  (in  other  than 
the  ATM  configuration)  was  89.59%  (see  Section  4.4).  Since  no  configuration  of 
CCSDS  parameters  achieved  both  of  these  levels  of  performance  simultaneously,  the 
"ATM-version"  was  compared  to  the  "best  of  both  worlds"  configuration.  For 
completeness,  however,  the  "ATM-version"  of  CCSDS  generated  7.35%  lower 
throughput  than  the  maximum  achievable,  and  0.11%  higher  data  quality. 

The  results  of  the  performance  comparison  suggest  that  further  exploration  of 
using  ATM,  or  an  ATM -CCSDS  hybrid,  in  the  DoD  test  range  community  is  warranted. 
Data  quality  in  the  ATM  configuration  was  essentially  the  same.  While  the  throughput 
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performance  of  the  ATM  protocol  was  lower  than  that  of  CCSDS  in  this  study,  the  results 
were  "close  enough"  that  with  further  "tuning"  the  ATM  protocol  may  be  able  to  offer 
comparable  throughput  performance.  It  is  also  worth  noting  that  the  performance 
differences  here  may  be  caused  by  differences  between  the  OPNET  model  and  real-world 
test  range  conditions  and  channel  BER.  Chapter  VI  presents  the  flight  test  results  in  the 
area  of  ATM/CCSDS  comparison. 


Table  6.  ATM  vs  CCSDS  -  A  Performance  Comparison 


Protocol 

Transfer  Frame 
Payload  Length 
(Bytes) 

Source  Packet  Payload 
Length  (Bytes) 

Data 

Quality  (%) 

Throughput 

(Bps) 

CCSDS 

1000 

1000 

87.83 

108,360.00 

ATM 

179 

173 

87.70 

101,572.76 

Percent  Difference  = 

-0.15% 

-6.26% 

4.7  Summary 

This  chapter  has  established  the  performance  of  the  CCSDS  protocol  in  the  DoD 
test  range  environment.  It  has  also  attempted  to  give  the  user  guidance  and  a  starting 
point  for  configuring  the  protocol's  parameters  to  best  satisfy  mission  needs.  The  results 
of  this  analysis  are  summarized  in  Table  7  below.  Finally,  this  chapter  established  a 
baseline  for  the  performance  of  the  ATM  protocol  in  the  DoD  test  range  environment. 
With  further  research,  it  is  possible  the  ATM  protocol,  alone  or  in  combination  with  the 
CCSDS  protocol,  could  expand  telemetry  downlink  performance  for  the  military  test 
community. 
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Table  7.  Summary  of  Modeling  and  simulation  Results 


Priority  Level  of 
Mission  Rqmts 

Reed- 

Solomon 

(on/off) 

TF 

Payload 

Length 

(Bytes) 

SP 

Payload 

Length 

(Bytes) 

Best 

Performing 

Configuration 

Other  Top 
Performing 
Configurations 

Throughput 

Data 

Quality 

100% 

0% 

ON 

Not  Recommended 

RS:  OFF 

TF:  1000 

SP:  1000 

OFF 

— 

500- 

2000 

50% 

50% 

ON 

Not  Recommended 

RS:  OFF 

TF:  1000 

SP:  1000 

OFF 

— 

— 

0% 

100% 

ON 

Any 

500- 

2000 

RS:  ON 

TF:  1000 

SP:  1400 

RS:  OFF 

TF:  1000 

SP:  1000 

OFF 

Any 

500- 

2000 
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CHAPTER  V  -  CONCLUSIONS  &  RECOMMENDATIONS  PRIOR  TO  FLIGHT 

TEST 


5.1  Introduction 

The  goal  of  this  research  was  to  evaluate  the  CCSDS  protocol  for  use  in  the  DoD 
test  community  and  attempt  to  optimize  it  for  specific  mission  objectives.  Three  CCSDS 
parameters  were  identified  as  having  a  potentially  significant  effect  on  the  performance 
of  the  protocol.  These  parameters  were:  transfer  frame  length,  source  packet  length,  and 
Reed-Solomon  encoding.  Each  parameter  was  evaluated  to  determine  what  role  it  played 
in  the  overall  performance  of  the  protocol,  which  was  measured  in  terms  of  throughput 
and  data  quality.  A  summary  of  the  findings  can  be  found  below.  A  detailed  explanation 
of  the  three  parameters,  as  well  as  the  two  measures  of  protocol  performance,  can  be 
found  in  Chapters  II  and  III.  Specific  details  leading  to  the  conclusions  listed  below  can 
be  found  in  Chapter  IV. 

5.2  Summary  of  Key  Results 

This  research  effort  was  broken  into  four  main  areas.  The  first  area  of  study 
focused  on  how  the  three  CCSDS  parameters  (transfer  frame  length,  source  packet 
length,  and  Reed-Solomon  encoding)  affect  data  throughput  and  how  each  parameter 
should  be  set  in  order  to  maximize  throughput.  This  knowledge  is  of  particular  use  to  a 
mission  where  maximizing  the  throughput  of  mission  data  is  of  particular  priority  for 
meeting  mission  objectives  (e.g.,  "video"  data).  With  regards  to  throughput,  the 
following  conclusions  were  made  based  on  the  modeling  and  simulation  results: 
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1.  Reed- Solomon  encoding  should  be  OFF  for  maximum  throughput 
performance. 

2.  A  transfer  frame  payload  length  between  600  and  1000  bytes  should  be  used 
to  obtain  top  throughput  performance. 

3.  A  source  packet  payload  length  between  500  and  2000  bytes  should  be  used  to 
obtain  top  throughput  performance. 

4.  Ultimate  solution:  Barring  other  constraints,  a  transfer  frame  payload  length 
of  1000  bytes,  source  packet  payload  length  of  1000  bytes,  and  Reed-Solomon 
encoding  OFF  should  be  used  to  obtain  the  highest  effective  data  throughput. 

The  second  area  of  study  focused  on  how  the  three  CCSDS  parameters  affected 
data  quality  and  how  each  should  be  set  in  order  to  maximize  data  quality.  This 
knowledge  is  of  particular  use  to  a  mission  where  maximizing  the  amount  of  mission  data 
transmitted  without  error  is  of  particular  priority  for  meeting  mission  objectives  (e.g., 
"memory"  data).  With  regards  to  data  quality,  the  following  conclusions  were  made 
based  on  the  modeling  and  simulation  results: 

1.  Transfer  frame  length  has  a  negligible  effect  on  the  resulting  data  quality. 

2.  Reed-Solomon  encoding  should  be  ON  for  maximum  data  quality. 

3.  Near-maximum  data  quality  (within  2%  of  maximum)  is  achievable  with 
Reed-Solomon  encoding  OFF. 

4.  A  source  packet  payload  length  between  500  and  2000  bytes  should  be  used  to 
obtain  top  data  quality  performance. 


67 


5.  Ultimate  Solution:  A  source  packet  payload  length  of  1400  bytes  with  Reed- 
Solomon  encoding  ON  should  be  used  to  obtain  the  highest  data  quality. 

6.  Runner-Up  Solution:  A  source  packet  payload  length  of  1000  bytes  with 
Reed-Solomon  encoding  OFF  can  be  used  to  obtain  top  data  quality  results. 

The  third  area  of  study  focused  on  how  the  three  CCSDS  parameters  affect  both 
data  throughput  and  data  quality  simultaneously  and  how  each  should  be  set  in  order  to 
obtain  the  best  simultaneous  throughput  and  data  quality.  For  this  evaluation,  throughput 
and  data  quality  were  given  equal  weighting.  This  knowledge  is  of  particular  use  to  a 
mission  where  both  throughput  and  data  quality  are  important  to  meeting  mission 
objectives.  With  regards  to  finding  a  “best  of  both  worlds”  solution,  the  following 
conclusions  were  made  based  on  the  modeling  and  simulation  results: 

1.  To  achieve  the  best  compromise  between  throughput  and  data  quality,  transfer 
frame  payload  length  should  be  between  600  and  1000  bytes. 

2.  To  achieve  the  best  compromise  between  throughput  and  data  quality,  source 
packet  payload  length  should  be  between  500  and  1400  bytes. 

3.  To  achieve  the  best  compromise  between  throughput  and  data  quality,  Reed- 
Solomon  encoding  should  be  OFF. 

4.  A  transfer  frame  length  of  1000  bytes,  source  packet  length  of  1000  bytes,  and 
Reed-Solomon  encoding  OFF  should  be  used  to  obtain  an  optimum 
combination  of  throughput  and  data  quality. 
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The  final  area  of  study  focused  on  comparing  the  CCSDS  and  ATM  packet 
protocols.  This  was  done  to  determine  whether  future  work  towards  using  the  ATM 
protocol  in  the  test  range  community  in  conjunction  with,  or  instead  of,  the  CCSDS 
protocol  is  justified.  The  two  protocols  were  compared  in  terms  of  throughput  and  data 
quality.  Overall,  performance  of  the  ATM  protocol  was  sufficiently  close  to  that  of 
CCSDS  to  warrant  further  investigation.  In  this  study,  throughput  attained  using  the 
ATM- version  was  6.26%  lower  than  that  with  CCSDS  and  data  quality  was  -0.15% 
lower. 

5.3  Recommendations  for  Further  Research 

Results  show  the  CCSDS  packet  telemetry  protocol  to  be  effective  for  the 
transmission  of  telemetry  data  in  the  DoD  test  range  community.  The  relationships 
between  the  primary  CCSDS  parameters  (transfer  frame  length,  source  packet  length,  and 
Reed-Solomon  encoding)  and  the  resulting  protocol  performance  (measured  in  terms  of 
throughput  and  data  quality)  were  mapped  and  general  conclusions  made  with  regards  to 
optimizing  the  protocol  to  meet  mission  needs.  This  research  meets  the  need  of  the  test 
community  for  configuring  equipment  for  sorties  involving  telemetry  data  transmission. 
Suggestions  for  future  areas  of  work  are  provided  below  for  continued  study  and  to 
optimize  the  CCSDS  protocol. 

In  the  conduct  of  this  research,  the  Edwards  AFB  test  range  was  modeled  using 
the  OPNET  modeling  tool.  Due  to  the  constraints  of  the  software  and  scope  of  the 
research,  certain  simplifying  assumptions  were  made  and  the  influence  of  certain 
environmental  parameters  eliminated  or  grouped  under  the  umbrella  of  “channel  BER”. 
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These  parameters  included  aircraft  altitude  and  range  from  the  receiver,  the  antenna 
pattern  on  the  aircraft,  weather,  and  test  range  location.  All  of  these  parameters  serve  to 
effectively  improve  or  worsen  channel  BER,  however  the  specific  effects  each  one  has  on 
overall  performance  was  not  explicitly  evaluated.  They  did,  however,  come  into  play 
during  the  flight  test  portion.  For  this  reason  there  is  value  to  be  gained  from  evaluating 
the  effects  of  these  factors  further. 

A  model  of  the  channel  BER  at  Edwards  AFB  was  an  integral  part  of  the  OPNET 
model  used  to  evaluate  the  CCSDS  protocol.  The  88- 10-2  breakdown  of  channel  errors 
used  in  the  model  was  based  as  closely  as  possible  on  previous  work  by  the  ARTM  JPO 
to  characterize  the  channel.  Characterizing  channel  error,  however,  is  difficult.  There 
are  many  factors  that  influence  channel  performance  on  any  particular  day,  including 
factors  discussed  in  the  previous  paragraph.  The  88- 10-2  channel  model  is  a  simplified 
solution  sufficient  for  the  scope  of  this  research.  For  future  study  it  may  prove  to  be 
inadequate.  Future  work  to  model  the  telemetry  downlink  or  improve  the  performance  of 
the  protocol  should  first  enhance  the  channel  BER  model  to  incorporate,  for  example,  the 
possibly  dynamic  effects  of  the  environmental- type  variables  discussed  above. 

Another  area  of  future  work  is  to  further  develop  the  connection  between  CCSDS 
configurations  and  actual  DoD  mission  requirements.  Only  three  mission-oriented 
priority  scenarios  were  considered:  maximize  throughput  without  regard  to  data  quality, 
maximize  data  quality  without  regard  to  throughput,  and  maximize  both  throughput  and 
data  quality  with  equal  priority.  The  world  is  not  usually  this  simple,  nor  are  telemetry 
downlink  requirements.  For  this  reason  there  is  value  to  be  gained  from  optimizing  the 
CCSDS  protocol  for  other  priority  scenarios.  This  could  be  as  simple  as  finding  the  best 
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configuration  for  a  75:25  priority  split,  or  it  could  be  maximizing  other  measures  of 
performance,  in  particular  data  latency,  which  will  be  useful  as  near- real- time 
applications  continue  to  grow. 

Finally,  this  research  demonstrated  the  potential  for  the  ATM  protocol  to  meet, 
and  possibly  exceed,  the  performance  of  the  CCSDS  protocol  in  the  DoD  test  range 
community.  Although  initially  designed  to  operate  on  networks  with  negligible  BERs, 
the  ATM  protocol  performed  adequately  when  BERs  were  significant.  Granted,  the 
evaluation  of  the  protocol  in  this  research  work  was  a  simple  baseline  test.  The  results 
were  favorable,  however,  adding  justification  for  further  investigation  into  using  the 
ATM  protocol  in  the  test  range  community.  This  may  gain  the  DoD  interoperability  with 
civilian  systems/networks  that  does  not  readily  exist  now. 
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CHAPTER  VI  -  FLIGHT  TEST 


6.1  Introduction 

This  chapter  describes  the  flight  test  program  associated  with  the  research 
discussed  in  previous  chapters.  It  summarizes  the  configuration,  execution,  data  analysis, 
results,  and  conclusions  of  the  flight  test.  Previous  chapters  describe  the  modeling  and 
simulation  of  the  CCSDS  packet  telemetry  protocol.  The  simulations  showed  a 
correlation  between  three  specific  CCSDS  protocol  parameters  and  the  resulting 
throughput  and  data  quality  performance  of  the  protocol.  The  primary  purpose  of  the 
flight  test  was  to  validate  these  findings  and  attempt  to  find  an  optimal  combination  of 
CCSDS  parameters  to  maximize  protocol  performance  based  on  mission  requirements. 

Flight  testing  was  conducted  from  5  to  31  October  2001,  at  Edwards  AFB, 
California  and  supported  the  ARTM  JPO,  also  located  at  Edwards  AFB.  The  responsible 
test  organization  was  the  412th  Test  Wing  located  at  Edwards  AFB.  Testing  was 
conducted  by  the  "NEED  INFO"  test  team,  United  States  Air  Force  Test  Pilot  School 
(USAF  TPS),  Class  01 A  using  a  Sabreliner  T-39A  passenger  jet.  One  airborne 
equipment/software  validation  sortie,  six  data  collection  sorties,  and  two  backup  sorties 
were  flown,  for  a  total  of  27  flight  hours. 

Preliminary  results  confirmed  the  correlation  between  the  previously  identified 
CCSDS  parameters  and  the  resulting  protocol  performance.  Further  testing  identified  a 
combination  of  parameters  that  would  maximize  data  throughput,  data  quality,  or  provide 
a  combined  "best  of  both  worlds"  solution.  The  complete  flight  test  report  is  in  [9]. 
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6.2  Test  Description 


6.2.1  Test  Item  Description.  The  test  item  was  the  CCSDS  packet  telemetry 
protocol.  This  protocol  was  discussed  at  length  in  Chapters  II  and  III,  and  will  only  be 
summarized  here.  The  three  CCSDS  protocol  parameters  identified  as  strongly 
influencing  the  performance  of  the  telemetry  system  are  source  packet  length,  transfer 
frame  length,  and  Reed- Solomon  encoding.  The  data  to  be  transmitted  between  sender 
and  receiver  is  organized  into  source  packets.  The  source  packets  used  in  this  study 
consisted  of  a  six  byte  header  and  variable  length  data  field  (from  1  to  65,536  bytes). 

The  source  packets  are  then  multiplexed  together  into  a  synchronous  stream  of  fixed- 
length  transfer  frames  for  transmission  to  the  ground.  The  transfer  frames  used  in  this 
study  consisted  of  an  eight  byte  header  and  variable  length  data  field  (from  1  to  1 107 
bytes).  During  the  simulation  portion  of  this  research  work,  the  transfer  frame  header 
was  six  bytes.  During  preparation  for  the  flight  test,  software  upgrades  mandated  an 
eight-byte  transfer  frame  header.  This  did  not  appear  to  significantly  affect  the  results. 

Reed- Solomon  is  the  optional  error  correction  code  capable  of  correcting  up  to  16 
byte  errors  in  each  block  of  223  bytes.  If  used,  an  additional  160  check  bytes  are 
appended  to  the  transfer  frame.  If  not  used,  an  additional  2  bytes  of  CRC  bytes  are  added 
to  provide  a  basic  error  detection  capability.  Finally,  four  synchronization  bytes  are 
attached  and  the  transfer  frame  is  ready  for  transmission.  Once  received  on  the  ground, 
the  process  is  reversed  to  retrieve  the  original  data  in  the  source  packets. 

Another  objective  of  the  flight  test  was  to  compare  the  performance  of  the  ATM 
and  CCSDS  protocols.  ATM  technology  is  a  form  of  packet- switched  transmission  that 
uses  fixed- sized  units,  called  cells,  to  transmit  data  between  sender  and  receiver.  Each 
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cell  is  53  bytes  long;  five  overhead  bytes  and  48  bytes  of  data.  This  protocol  was 
originally  designed  for  networks  with  very  low  BERs. 

The  two  metrics  used  were  throughput  and  data  quality.  Throughput  is  defined  as 
the  number  of  data  bytes  successfully  received  by  the  ground  node  per  unit  time  (bytes 
per  second).  Data  quality  is  defined  as  the  percentage  of  successfully  received  source 
packets  at  the  ground  node  versus  the  total  number  transmitted.  This  statistic  is 
expressed  as  a  percentage,  with  100%  indicating  error-free  data  transmission.  In  both 
cases,  a  byte  was  considered  successfully  received  if  it  was  part  of  a  transfer  frame  that 
was  successfully  received.  A  transfer  frame  was  successfully  received  if  the  number  of 
bytes  in  error  is  within  allowable  error  tolerances.  The  error  tolerances  depended  on 
whether  Reed-Solomon  encoding  was  being  used  or  not.  If  not  used,  a  transfer  frame 
was  considered  successfully  received  if  it  contained  no  byte  errors.  If  Reed-Solomon  was 
used,  a  transfer  frame  was  considered  successfully  received  if  the  number  of  bytes  errors 
was  less  than  the  number  correctable  by  Reed-Solomon. 

6.2.2  Test  Objectives.  The  flight  test  program  had  the  following  four 
objectives: 

•  Objective  1:  Observe  the  effects  of  transfer  frame  payload  length,  source  packet 
payload  length,  and  Reed-Solomon  encoding  on  throughput  performance  of  the  CCSDS 
packet  telemetry  protocol.  Determine  the  optimal  combination  of  these  parameters  to 
maximize  throughput  of  error- free  data. 

•  Objective  2:  Observe  the  effects  of  transfer  frame  payload  length,  source  packet 
payload  length,  and  Reed-Solomon  encoding  on  data  quality  performance  of  the  CCSDS 
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packet  telemetry  protocol.  Determine  the  optimal  combination  of  these  parameters  to 
maximize  the  percentage  of  error- free  data. 

•  Objective  3:  Determine  and  demonstrate  the  combination  of  transfer  frame 
payload  length,  source  packet  payload  length,  and  Reed- Solomon  encoding  parameters 
that  provides  the  best  compromise  between  throughput  and  data  quality.  Throughput  and 
data  quality  will  be  weighted  equally  during  the  evaluation. 

•  Objective  4:  Collect  data  in  order  to  demonstrate  the  potential  performance  of 
the  ATM  packet  protocol  in  the  aeronautical  telemetry  environment.  This  will  be  done  by 
configuring  the  CCSDS  parameters  to  mimic  the  data-to-overhead  ratio  of  an  ATM  cell. 
Compare  the  resulting  throughput  and  data  quality  with  the  CCSDS  performance  achieved 
in  Objectives  1-2. 

6.2.3  Test  Aircraft.  The  T-39A  (S/N  60-3478)  test  aircraft,  a  Sabreliner  T-39A 
passenger  jet  like  the  one  shown  in  Figure  25,  was  provided  and  operated  by  the  418th 
Flight  Test  Squadron.  The  T-39A  aircraft,  capable  of  flying  the  maneuvers/profiles  to 
fully  exercise  the  CCSDS  telemetry  protocol,  is  a  low  wing,  twin-jet,  monoplane  with 
axial- flow  engines  mounted  on  each  side  of  the  aft  fuselage.  Two  equipment  racks  were 
installed  in  the  passenger  compartment  of  the  T-39A  in  place  of  two  of  the  normal 
passenger  seats.  The  test  aircraft  provided  28  VDC  electrical  power  to  the  equipment 
racks  and  also  locations  on  the  upper  and  lower  fuselage  for  the  required  antennas. 
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Figure  25.  T-39A  Sabreliner 


6.2.4  Test  Range.  All  testing  was  accomplished  in  the  R-2515  complex  at 
Edwards  AFB,  California.  The  ARTM  JPO  S250  Comm  Shelter  shown  in  Figure  26  was 
used  to  capture  and  process  the  signals  transmitted  from  the  test  aircraft.  The  S250 
shelter  met  all  telemetry  processing  requirements  and  was  specially  configured  for  the 
mission.  Normal  operational  telemetry  facilities  were  not  required. 


Figure  26.  S250  Comm  Shelter 
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6.3  Limitations  &  Assumptions 


6.3.1  Channel  BER.  Based  on  previous  flight  test  work  by  the  ARTM  JPO,  as 
described  in  Appendix  A  (Section  A. 3),  the  channel  used  in  the  simulations  followed  a 
88%,  10%,  2%  breakdown  of  error- free,  cluster  error,  and  burst  error  periods, 
respectively.  The  first  sortie  in  the  flight  test  program  was  dedicated  to  choosing  a 
location  for  the  racetrack  flight  path  that  would  roughly  achieve  a  similar  channel  BER. 

It  quickly  became  evident  that  this  would  be  difficult  as  even  the  most  error-prone 
locations  on  Edwards  AFB  were  producing  only  a  few  percent  of  total  error.  This  is 
attributed  to  new  antenna/receiver  equipment  installed  after  the  channel  characterization 
work  that  was  the  basis  for  the  channel  modeling  used  in  the  OPNET  simulations.  Rather 
than  use  the  "better"  channel  for  the  flight  test,  it  was  decided  to  install  an  attenuator  on 
the  receiver  in  order  to  artificially  worsen  the  channel  and  attempt  to  get  closer  to  the 
desired  88-10-2  breakdown  of  errors.  The  actual  breakdown  achieved  was  roughly  95-4- 
1.  This  was  accomplished  using  a  40  dB  attenuator;  attenuating  the  signal  greater  than 
that  caused  the  noise  level  to  start  masking  the  signal.  The  decision  to  degrade  the 
channel  was  made  for  two  reasons.  First,  the  results  would  be  easier  to  compare  with  the 
modeling  and  simulation  results.  In  other  words,  channel  BER  is  assumed  not  to  be  a 
significant  variable  in  the  experiment.  Actually,  there  was  some  variance  between  the 
experimental  and  flight  test  BERs.  The  second  reason  is  that  the  larger  BER  made  it 
easier  to  illustrate  the  benefits  and  drawbacks  due  to  each  CCSDS  parameter 
configuration.  This  was  particularly  the  case  when  demonstrating  the 
advantages/disadvantages  of  Reed- Solomon  encoding,  namely,  with  few  errors  to  correct, 
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the  performance  gained  using  Reed- Solomon  was  insignificant.  The  larger  BER  made  it 


possible  to  clearly  distinguish  the  advantages  of  various  configurations. 

6.3.2  Software  Restrictions  on  Transfer  Frame  Length.  According  to  the  CCSDS 
Blue  Book  [4,5],  transfer  frame  length  can  take  on  any  value  up  to  1115  bytes  whether 
Reed-Solomon  encoding  is  used  or  not.  The  Avtec  software  implementation  [3]  used  by 
the  ARTM  JPO,  restricted  transfer  frame  length  to  a  single  value  of  939  bytes  if  Reed- 
Solomon  encoding  was  ON,  but  let  it  take  on  any  value  up  to  1115  bytes  if  Reed- 
Solomon  encoding  was  OFF.  This  was  intentionally  done  by  the  software  programmers 
to  maximize  the  data- to- overhead  ratio  of  the  transfer  frame  when  160  bytes  of  overhead 
are  added  due  to  Reed-Solomon  encoding.  In  the  simulation  model  (c.f.,  Chapters  III  and 
IV),  transfer  frame  length  was  not  restricted  when  Reed-Solomon  was  ON.  As  will  be 
shown  below,  this  did  not  significantly  affect  the  results  with  regard  to  throughput 
performance.  However,  with  respect  to  data  quality,  some  discrepancies  between  the 
experimental  and  flight  test  results  were  noted.  These  are  discussed  further  in  Section 
6.6. 


6.3.3  Software/Hardware  Limitations.  All  "events"  in  the  telemetry  downlink 
process  resulted  in  an  interrupt  in  the  computer  software/hardware  executing  the  CCSDS 
packet  protocol  implementation.  "Events"  include  generation  of  frames  and  packets, 
transmission  of  frames,  and  receipt  of  frames.  One  event  that  generates  a  large  number 
of  interrupts  is  the  creation  of  source  packets.  The  smaller  the  size  of  the  source  packet, 
the  more  frequently  interrupts  occurred.  As  source  packet  size  was  decreased,  there  was 
a  point  where  the  software/hardware  could  no  longer  keep  up  with  the  interrupts  and  the 
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computer  would  crash.  Therefore,  the  smallest  source  packet  payload  length  tested  was 
30  bytes.  The  smallest  transfer  frame  payload  length  in  the  test  matrix,  50  bytes,  did  not 
result  in  interrupt  problems. 

6.4  Flight  Test  Execution 

A  total  of  61  test  points  were  flown  and  data  was  collected  to  determine  the  effects 
of  transfer  frame  length,  source  packet  length,  and  Reed-Solomon  encoding  on  data  quality. 
The  test  points  are  listed  in  Table  8  below.  For  each  test  point,  the  telemetry  system  was 
configured  to  transmit  a  known  data  stream  to  the  ground  station  and  the  test  aircraft  flew  a 
predetermined,  twelve  (12)  minute  racetrack  pattern  at  4500  ±  50  feet  mean  sea  level 
(MSL)  over  CORDS  Road  in  the  R-2515  Edwards  AFB  test  area.  The  racetrack  pattern  is 
illustrated  in  Figure  27.  After  test  completion,  the  known  stream  was  compared  to  the  data 
stream  received  at  the  ground  station. 

6.5  Post -Flight  Data  Processing 

A  pre- determined  test  sequence  was  transmitted  from  the  aircraft  during  each  pass 
through  the  route.  The  chosen  route  exposed  the  telemetry  data  stream  to  both  "error- 
free"  and  "error-prone"  areas  to  evaluate  the  robustness  of  the  CCSDS  protocol.  The 
transmitted  stream  was  recorded  to  CD-R  media,  as  was  the  stream  that  was  ultimately 
received  at  the  ground  comm- shelter.  Also  recorded  was  the  total  transmission  time. 
Transmission  time  is  defined  as  the  time  from  the  transmission  of  the  first  byte  to  the  last 
byte  during  each  pass  around  the  route  (one  pass  =  one  data  point).  At  the  completion  of 
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Table  8.  Flight  Test  Data  Points 
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each  flight,  this  data  was  reduced  to  produce  the  metrics  for  the  corresponding 
objective(s).  Data  reduction  consisted  of  comparing  the  sent  and  received  streams  with 
the  goal  of  determining  the  number  of  source  packets  and  ultimately  the  number  of  data 
bytes  successfully  received.  An  in-house  software  program  written  by  the  ARTM  JPO 
was  used  to  facilitate  a  byte- wise  comparison  of  the  transmitted  and  received  stream  to 
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O  =  location  of  S250  ground  station 
Figure  27.  Racetrack  Route 


determine  the  number  of  successfully  received  source  packets.  The  number  of  data  bytes 
successfully  received  was  calculated  by  multiplying  the  number  of  successfully  received 
source  packets  by  the  length  of  a  source  packet  data  payload  (in  bytes).  Source  packet 
payload  length  was  constant  during  each  data  point. 

Analysis  of  the  data  and  results  obtained  in  Objectives  1  and  2  was  performed  by 
two  methods.  The  first  method  was  an  analysis  of  variation  (ANOVA)  with  the 
combined  maximization  of  throughput  and  data  quality  as  the  desired  output.  The  second 
method  was  inspection  of  processed  data  in  the  form  of  a  contour  plot  illustrating  the 
overall  variation  of  the  dependent  variables  with  respect  to  the  independent  variables  on  a 
single  chart.  In  both  methods,  throughput  and  data  quality  were  equally  desirable  in  the 
evaluation. 
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The  following  equation  was  used  to  calculate  throughput: 

^  ,  #  error  free  bytes  received 

Throughput  = - - - 

total  transmiss  ion  time  (sec) 

The  following  equation  was  used  to  calculate  data  quality: 

^  #  source  packets  successful  ly  received  .... 

Data  Quality  = - - - - - x  100 

total  number  of  source  packets  sent 

The  goal  of  Objective  4  was  to  demonstrate  the  potential  performance  of  the 
ATM  packet  protocol  in  the  Department  of  Defense  aeronautical  telemetry  environment. 
This  was  done  by  configuring  the  CCSDS  parameters  to  mimic  the  data- to- overhead  ratio 
of  an  ATM  cell,  and  comparing  the  optimum  throughput  and  data  quality  performance  of 
both  protocols.  For  the  CCSDS  case,  the  maximum  simultaneously  achievable 
throughput  and  data  quality,  as  determined  in  Objective  3,  was  used  for  the  comparison. 
Throughput  and  data  quality  values  used  for  the  ATM  protocol  were  the  arithmetic  mean 
of  data  obtained  on  two  data  runs. 

6.6  Flight  Test  Experimental  Results  and  Analysis 

6.6.1  Objective  1.  As  shown  in  Figure  28,  effective  throughput  was  dependent 
on  transfer  frame  length.  Figure  28  through  Figure  31  show  selected  data  to  illustrate 
trends  in  tested  parameters.  Tables  and  plots  of  collected  data  are  in  Appendix  F.  In 
general,  throughput  increased  as  transfer  frame  length  was  increased  until  transfer  frame 
payload  length  reached  800  bytes,  where  throughput  began  to  drop  off.  Further  testing 
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may  be  able  to  locate  a  more  precise  peak.  This  information  may  be  of  value  if  mission 
objectives  necessitate  the  transmission  of  data  with  minimum  delay  but  with  some 
flexibility  with  regards  to  loss  of  data.  Given  that  the  collected  data  has  only  a  small 
spread,  the  benefit  in  finding  a  precise  peak  is  likely  not  worth  the  time  and  resources  to 
find  it. 


Aircraft:  T-39A 

Altitude:  4500ftMSL 

Frequency:  1455.5  MHz 

Tail#:  61-0478 

Airspeed:  200KIAS 

Location:  Edwards  AFB,  CA 

Dates:  9-31  Oct  01 

Transmit  Range:  8-20  NM 

Peak  Transfer  Rate:  125000  bytes/sec 

Figure  28:  Throughput  Variation  with  Transfer  Frame  Payload  Length 

(Trendlines  shown  are  hand-drawn) 


As  Figure  29  shows,  effective  throughput  is  also  dependent  on  source  packet 
length.  Throughput  performance  was  the  highest  for  source  packet  lengths  between  200 
and  2000,  but  decreased  for  source  packet  lengths  below  200  and  above  2000  bytes.  A 
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source  packet  length  of  500  bytes  consistently  produced  the  best  throughput  performance. 
Further  testing  may  be  able  to  locate  a  more  precise  peak,  however,  given  there  is  only  a 
2%  difference  between  the  high  and  low  throughput  values  in  the  200  to  2000  byte  source 
packet  range,  the  benefit  gained  in  finding  a  precise  peak  is  again  likely  not  worth  the 
effort. 


Aircraft:  T-39A 

Altitude:  4500ftMSL 

Frequency:  1455.5  MHz 

Tail#:  61-0478 

Airspeed:  200KIAS 

Location:  Edwards  AFB,  CA 

Dates:  9-31  Oct  01 

Transmit  Range:  8-20  NM 

Peak  Transfer  Rate:  125000  bytes/sec 

Figure  29:  Throughput  Variation  with  Source  Packet  Payload  Length 

(Trendlines  shown  are  hand-drawn) 


Figure  29  also  shows  the  effect  of  Reed- Solomon  encoding  on  throughput 
performance.  In  general,  throughput  performance  followed  the  same  trend  as  the  non- 
Reed- Solomon  cases,  however  throughput  performance  overall  was  lower  with  the 
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exception  of  the  50  byte  transfer  frame  length  case.  With  Reed- Solomon  encoding  ON, 
the  highest  throughput  was  97,931  Bps  (at  source  packet  length  of  2000).  This  is  16% 
lower  than  the  maximum  achievable  throughput  with  Reed-Solomon  encoding  turned 
OFF.  The  data  point  at  source  packet  length  of  500  bytes  fell  outside  the  general 
trendline  and  may  have  been  an  outlier.  This  point  was  not  reflown  due  to  flying  time 
constraints,  however  using  a  statistical  software  package,  the  predicted  throughput  for 
that  source  packet  length  is  99017  Bps.  Using  this  predicted  value,  throughput 
performance  is  still  15%  below  the  maximum  achievable  with  Reed-Solomon  OFF. 
Therefore,  the  test  team  concluded  that  Reed-Solomon  encoding  should  be  off  for 
maximum  throughput  performance. 

As  noted  earlier,  the  Avtec  software  implementation  [3]  used  by  the  ARTM  JPO 
restricted  transfer  frame  length  to  a  single  value  (939  bytes)  if  Reed-Solomon  encoding 
was  ON,  but  let  it  take  on  any  value  up  to  1115  bytes  if  Reed-Solomon  encoding  was 
OFF.  In  the  modeling  and  simulation  work  done  in  conjunction  with  this  flight  test, 
transfer  frame  length  was  not  restricted  when  Reed-Solomon  was  ON.  However,  the 
results  of  that  work  were  not  significantly  different  than  the  results  demonstrated  during 
the  flight  test  and  do  not  require  further  investigation  with  regards  to  throughput 
performance. 

The  configuration  of  CCSDS  parameters  that  yielded  the  best  throughput 
performance  was  a  transfer  frame  length  of  800  bytes,  source  packet  length  of  500  bytes, 
and  Reed-Solomon  encoding  OFF.  This  solution  yielded  an  overall  throughput  of 
116,551  Bps.  Given  that  the  worst-case  99%  confidence  interval  on  the  throughput  data 
collected  was  ±1877  Bps,  throughput  values  reported  are  estimated  to  be  accurate  to 
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within  ±1.6%.  Analysis  of  variance  (ANOVA)  [8]  on  the  data  showed  that  transfer  frame 
length  contributed  41.3%  to  the  resulting  throughput,  source  packet  length  36%,  and 
Reed-Solomon  encoding  12%.  The  remaining  11%  was  due  to  the  interaction  between 
transfer  frame  and  source  packet  length.  It  was  therefore  concluded  that  a  transfer  frame 
length  of  800  bytes,  source  packet  length  of  500  bytes,  and  Reed-Solomon  encoding  off 
should  be  used  to  obtain  maximum  throughput. 

The  flight  test  results  generally  agree  with  the  simulation  conclusions.  The 
simulation  results  suggested  that  throughput  could  be  maximized  using  a  transfer  frame 
payload  length  in  the  range  600-1000  bytes,  a  source  packet  payload  length  in  the  range 
500-2000  bytes,  and  Reed-Solomon  encoding  OFF.  The  configuration  that  yielded  the 
best  throughput  performance  during  the  flight  test  fell  within  these  bounds.  Both  sets  of 
results  found  similar  trends  and  relationships  between  the  protocol  parameters  and  the 
resulting  throughput.  With  regard  to  transfer  frame  length,  throughput  continued  to 
increase  through  the  entire  range  during  the  simulation  (i.e.,  for  TF  =  1000),  whereas 
during  the  flight  test  throughput  started  to  decrease  after  800  bytes.  This  is  most  likely 
due  to  the  differences  between  the  test  model  and  actual  flight  test  conditions.  As  for 
source  packet  length,  both  the  simulation  and  flight  test  narrowed  in  on  a  similar  range  of 
possible  source  packet  lengths,  500-2000  bytes  and  200-2000  bytes,  respectively.  Both 
the  simulation  and  flight  test  results  clearly  demonstrated  the  advantages  of  not  using 
Reed-Solomon  encoding  to  maximize  throughput.  A  final  difference  in  results  was  the 
configuration  that  achieved  maximum  throughput:  (TF  =  1000,  SP  =  1000,  RS  OFF) 
from  the  simulation  results  versus  (TF  =  800,  SP  =  500,  RS  OFF)  from  the  flight  test 
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results.  This  discrepancy,  however,  is  insignificant  and  is  most  likely  due  to  differences 
between  the  test  model  and  actual  flight  test  conditions. 


6.6.2  Objective  2.  Figure  30  shows  the  effect  of  transfer  frame  length  on  data 
quality.  As  predicted,  the  data  demonstrated  that  there  was  little  correlation  between 
transfer  frame  length  and  data  quality  and  no  specific  trends  were  drawn  from  the  data. 
An  ANOVA  of  the  data  concluded  that  transfer  frame  length  contributed  to  6.8%  of  the 
data  quality.  The  ANOVA  also  indicated  an  interaction  between  source  packet  and 
transfer  frame  length  contributing  to  24%  of  the  data  quality,  although  the  test  team  was 
unable  to  determine  the  specific  reason  for  the  interaction. 
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Figure  30:  Data  Quality  Variation  with  Transfer  Frame  Payload  Length 

(Trendlines  shown  are  hand-drawn) 
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Figure  31  shows  the  effect  of  source  packet  payload  length  on  data  quality,  with 
the  payload  length  given  on  a  logarithmic  scale.  As  predicted,  the  data  quality  decreased 
as  source  packet  length  increased  with  a  maximum  average  data  quality  of  97.1% 
occurring  with  a  source  packet  length  of  194  bytes.  Flight  test  data  also  showed  that  data 
quality  for  source  packet  lengths  of  30  bytes  aggregated  into  two  groups,  one  having  a 
data  quality  5%  lower.  This  may  be  due  to  the  specific  hardware  implementation  used 
and  limits  on  producing  very  small  source  packets  at  rapid  rates.  An  ANOVA  evaluation 
of  the  flight  test  data  concluded  that  source  packet  length  contributed  up  to  65%  to  data 
quality. 
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Figure  31:  Data  Quality  Variation  with  Source  Packet  Payload  Length 

(Trendlines  shown  are  hand-drawn) 
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Due  to  restrictions  imposed  by  the  CCSDS  implementation  software,  Reed- 
Solomon  encoding  could  only  be  tested  with  a  transfer  frame  payload  length  of  939  bytes 
(1119  bytes  total  transfer  frame  length).  The  collected  data  indicated  that  Reed- Solomon 
encoding  may  decrease  data  quality,  rather  than  increasing  it  as  was  predicted  by  the 
modeling  and  simulation  work.  An  ANOVA  of  the  data  generated  a  negligible 
contribution  (0.02%),  indicating  that  the  effect  of  RS  encoding  is  probably  insignificant 
for  the  tested  configurations.  However,  the  absence  of  data  at  multiple  transfer  frame 
lengths  prevented  a  more  in-depth  evaluation  concerning  the  use  of  Reed- Solomon 
encoding.  It  was  therefore  concluded  that  the  effects  of  Reed- Solomon  encoding  on  data 
quality  with  the  transfer  frame  length  restriction  removed  should  be  investigated. 

The  configuration  of  CCSDS  parameters  that  yielded  the  best  data  quality  was  a 
source  packet  payload  length  of  194  bytes  with  no  Reed-Solomon  encoding.  This 
configuration  yielded  an  average  data  quality  of  97.1%.  It  was  therefore  concluded  that  a 
source  packet  length  of  194  bytes  with  Reed-Solomon  encoding  off  should  be  used  to 
obtain  maximum  data  quality. 

There  is  some  discrepancy  between  the  simulation  and  the  flight  test  data  quality 
results.  Both  agreed  that  transfer  frame  length  is  not  a  factor  in  determining  data  quality. 
Both  found  a  similar  relationship  between  packet  length  and  data  quality.  The  range  of 
source  packet  payload  lengths  identified  to  maximize  data  quality  differed,  however: 
500-2000  bytes  from  the  simulations  versus  194  bytes  from  the  flight  test  results.  The 
simulations  identified  a  very  slight  advantage  to  using  Reed-Solomon  whereas  the  flight 
tests  did  not.  There  are  a  couple  of  items  to  note  about  these  differences.  First,  Reed- 
Solomon  testing  during  the  flight  test  was  limited  due  to  software  restrictions  on  transfer 
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frame  length.  Granted,  it  was  concluded  that  transfer  frame  length  does  not  play  a  role  in 
determining  data  quality;  nonetheless,  it  limited  the  amount  of  data  collected  with  Reed- 
Solomon  ON.  Second,  the  advantage  of  using  Reed- Solomon  identified  in  the 
simulations  was  less  than  2%  in  terms  of  throughput.  Given  better  channel  conditions, 
the  advantages  of  Reed- Solomon  would  be  even  smaller.  Finally,  considering  source 
packet  lengths  can  range  from  7  bytes  to  over  65,000  bytes,  the  differences  in  source 
packet  ranges  are  not  that  significant  and  are  most  likely  due  to  differences  between  the 
model  and  actual  flight  test  conditions. 

6.6.3  Objective  3.  As  indicated  from  the  results  of  Objectives  1  and  2,  Reed- 
Solomon  encoding  OFF  resulted  in  a  significant  improvement  in  throughput  and  had  little 
effect  on  data  quality  within  the  limited  parameters  tested.  Analysis  of  the  combined 
results  indicated  that  the  optimum  combination  of  throughput  and  data  quality  was 
achieved  with  Reed- Solomon  encoding  OFF,  as  well. 

Both  the  ANOVA  and  the  contour  plot  (Figure  32)  suggest  that  the  best 
throughput  and  data  quality  combination  occurs  with  a  transfer  frame  length  of  800  bytes 
and  a  source  packet  length  of  500  bytes.  Since  Objective  2  results  indicated  that  data 
quality  did  not  vary  significantly  with  transfer  frame  length,  the  fact  that  the  best 
combined  performance  occurred  at  the  transfer  frame  length  for  optimum  throughput  was 
expected.  However,  the  reason  that  the  source  packet  length  for  optimum  throughput 
matched  that  for  best  combined  performance  was  less  obvious,  until  observing  the 
contour  plot.  Recall  that  the  source  packet  length  for  optimum  data  quality  was  194 
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bytes.  Figure  32  illustrates  that  in  the  area  corresponding  to  a  transfer  frame  length  of 
800  bytes  and  source  packet  lengths  between  approximately  200  and  500  bytes,  the  slope 
of  data  quality  results  are  extremely  shallow  when  compared  to  those  of  throughput 
results.  This  indicates  that  changing  source  packet  length  from  194  bytes  to  500  bytes 
would  have  very  little  effect  on  data  quality  but  could  noticeably  improve  throughput.  It 
was  therefore  concluded  that  a  transfer  frame  length  of  800  bytes  and  source  packet 
length  of  500  bytes  with  Reed-Solomon  encoding  off  should  be  used  to  obtain  an 
optimum  combination  of  throughput  and  data  quality. 

6.6.4  Objective  4.  Table  9  shows  the  results  of  the  CCSDS  /  ATM  protocol 
comparison8 9.  Overall,  these  results  agreed  with  the  results  of  the  modeling  and 
simulation.  One  item  of  note  is  that  the  CCSDS  equivalent  configuration  was  (TF  =198 
bytes,  SP  =  192  bytes)  versus  (TF  =  179  bytes,  SP  =  173  bytes)  used  in  the  simulations. 
This  was  due  to  the  increase  in  size  of  the  transfer  frame  header  to  8  bytes  due  to 
requirements  by  the  Avtec  software  used  to  implement  the  CCSDS  protocol. 

Data  quality  between  the  two  protocols  was  not  significantly  different  (0.21% 
decrease  using  ATM).  This  was  well  within  the  error  margins  of  the  data  and  also 
consistent  with  predictions  (see  Table  6).  Throughput  performance  was  6.47%  higher 
using  CCSDS.  This  difference  could  be  partially  accounted  for  by  error  margins  in  the 
data,  or  condition  variations  on  the  days  the  test  points  were  flown.  It  was  not 
determined  significant  enough  to  discourage  further  study  of  the  ATM  protocal  for  DoD 

8  In  Figure  32,  four  data  points  were  discarded  due  to  noise  in  the  TM  signal.  These  points  were  replaced 
with  a  linear  interpolation  of  adjacent  points. 

9  A  sample  size  of  two  yielded  a  confidence  level  of  80%.  Throughput  data  is  accurate  to  within±1930 
Bps.  Data  quality  data  is  accurate  to  within  ±1.57  percentage  points. 
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test  &  evalutation,  especially  when  considering  the  potential  benefits  of  civilian  sector 
interoperability.  Overall,  data  quality  and  throughput  performance  using  the  ATM 
protocol  was  sufficiently  close  to  that  of  CCSDS.  These  results  demonstrate  cause  for 
further  study  of  the  ATM  protocol  for  DoD  test  and  evaluation  telemetry  needs.  An 
ATM  airborne  testbed  using  ATM- specific  equipment  would  adequately  display  the 
capabilities  of  the  protocol.  It  was  therefore  concluded  that  further  exploration  of  using 
the  ATM  protocol  in  the  DoD  test  environment  should  be  accomplished. 
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Figure  32:  Contour  Plot  of  Flight  Test  Data 
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Table  9.  Flight  Test  CCSDS/ATM  Protocol  Performance  Comparison 


Protocol 

Transfer  Frame 
Payload  Fength 
(Bytes) 

Source  Packet  Payload 
Fength  (Bytes) 

Data 

Quality  (%) 

Throughput 

(Bps) 

CCSDS 

800 

500 

97.1 

115,357 

ATM 

198 

192 

96.9 

107,899 

Percent  Difference  = 

-0.21% 

-6.47% 

6.7  Reconfiguration  of  Simulation  Model  to  Match  Flight  Test  Conditions 

During  the  execution  of  the  flight  test,  the  channel  was  characterized  by 
approximately  95%  error- free  behavior,  4%  cluster- error  behavior,  and  1%  burst-error 
behavior.  This  was  significantly  different  from  the  simulation  channel  model,  which  was 
characterized  by  approximately  88%  error- free  behavior,  10%  cluster-error  behavior,  and 
2%  burst-error  behavior.  In  most  cases,  the  simulation  and  flight-test  results  matched 
despite  the  differences  in  channel  behavior,  however  to  further  assess  the  effects  of  the 
channel  BER  on  CCSDS  performance,  the  simulation  channel  model  was  reconfigured  to 
follow  the  95-4-1  breakdown  of  error.  In  addition,  transfer  frame  header  size  was 
increased  by  two  bytes,  as  was  the  case  during  flight  test  due  to  Avtec  software 
requirements.  The  initial  73  test  cases,  plus  24  secondary  test  cases,  were  rerun  using  the 
modified  model.  The  secondary  test  cases  were  again  necessary  to  further  define  the 
relationship  between  source  packet  length  and  data  quality.  For  the  most  part,  the  new 
simulation  results  supported  the  conclusions  made  after  the  first  simulation  sequence 
using  the  88- 10-2  channel  model10.  The  results  also  shed  light  on  the  possible 
significance  of  environmental  variables,  such  as  atmospheric  effects  and  antenna 

111  A  sample  size  of  five  yielded  a  worst-case  confidence  level  of  90%.  Throughput  data  is  accurate  to 
within  ±127  Bps.  Data  quality  data  is  accurate  to  within  +0.103  percentage  points. 
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position,  in  the  telemetry  downlink.  A  summary  of  the  results  of  the  second  simulation 
sequence  is  presented  in  this  section.  The  throughput  and  data  quality  results  in  their 
entirety  are  provided  in  Appendix  G. 

With  regards  to  throughput,  the  results  using  the  95-4-1  channel  model  were  no 
different  than  during  the  simulation  sequence  using  the  88-10-2  channel  model. 
Throughput  again  increased  as  transfer  frame  length  increased.  A  transfer  frame  payload 
length  of  1000  bytes  produced  the  highest  throughput,  with  payload  lengths  between  600 
and  1000  bytes  again  producing  near- maximum  performance.  Source  packet  payload 
lengths  between  500  and  6000  bytes  produced  the  best  throughput  performance,  which 
was  generally  in  agreement  with  the  results  of  the  previous  simulation  results.  The  wider 
range  of  possible  source  packet  lengths  is  consistent  with  the  improvement  in  the  channel 
BER.  During  the  flight  test,  throughput  began  to  drop  off  around  a  source  packet  payload 
length  of  2000  bytes,  whereas  in  the  95-4-1  simulation,  throughput  was  high  up  to  a 
source  packet  payload  length  of  6000  bytes.  The  difference  is  most  likely  due  to  the 
environmental  type  errors  that  existed  in  the  Edwards  test  range,  but  were  not  explicitly 
included  in  the  simulation  model.  With  a  "cleaner"  channel  in  the  simulator,  longer 
source  packets  were  able  to  successfully  navigate  the  channel.  A  source  packet  payload 
length  of  2000  bytes  consistently  produced  the  highest  data  throughput  in  the  95-4-1 
simulations,  and  Reed-Solomon  OFF  was,  again,  clearly  more  advantageous. 

Analysis  of  data  quality  performance  using  the  reconfigured  channel  model  again 
showed  little  correlation  between  transfer  frame  length  and  the  resulting  data  quality. 
Source  packet  payload  lengths  between  500  and  6000  bytes  produced  the  best  data 
quality  performance.  This  was  similar  to  the  results  of  the  simulation  runs  using  the  88- 
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10-2  channel  model.  A  payload  length  of  1000-2000  bytes  consistently  produced  the 
highest  data  quality.  Again,  the  wider  range  of  possible  source  packet  lengths  is 
consistent  with  the  improvement  in  the  channel  BER.  As  seen  in  prior  simulation  results, 
there  was  a  slight  improvement  in  data  quality  with  Reed- Solomon  ON,  although  the 
improvement  was  less  than  1.4%.  This  is  demonstrated  in  Figure  33.  Using  the  88-10-2 
simulation  model,  the  improvement  in  data  quality  with  Reed- Solomon  ON  was  up  to 
2%.  As  expected,  the  advantages  gained  by  Reed-Solomon  decreased  as  the  channel 
improved.  Analysis  of  the  flight  test  data  showed  that  data  quality  actually  decreased  by 
up  to  4.4%  (the  average  decrease  was  less  than  3%)  with  Reed-Solomon  ON.  The 
difference  between  the  simulation  and  the  flight  test  results  is  most  likely  due  to  dynamic 
elements  in  the  test  range  environment  and  flight  test  conditions  that  were  not  explicitly 
incorporated  into  the  simulation  channel  model,  such  as  antenna  patterns  and  aircraft 
movement  relative  to  the  ground  station.  The  simulation  and  flight  test  results  suggest 
that  any  advantage  gained  by  turning  Reed-Solomon  ON  is  small,  and  turning  it  ON 
could  actually  decrease  data  quality  as  was  the  case  during  the  flight  testing  at  Edwards 
AFB. 

Using  the  method  of  analysis  used  previously  with  the  88-10-2  simulation  model, 
the  95-4-1  simulation  data  suggests  that  to  achieve  the  best  combined  throughput  and 
data  quality,  transfer  frame  payload  length  should  be  between  600-1000  bytes,  source 
packet  payload  length  should  be  from  500  -  6000  bytes,  and  Reed-Solomon  OFF.  Figure 
34  shows  a  contour  plot  of  the  throughput  and  data  quality  results  from  the  95-4-1 
simulation  model  overlaid.  As  with  previous  analysis  of  both  simulation  and  flight  test 
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data,  the  configuration  yielding  the  best  compromise  was  also  the  configuration  yielding 


the  best  throughput  performance. 
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Payload  Length 

o  200  bytes  (no  RS) 
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Figure  33.  Effects  of  Reed-Solomon  on  Data  Quality  Using  95-4-1  Simulation  Model 

(Trendlines  shown  are  hand-drawn) 


Table  10  shows  how  the  "ATM- version"  of  CCSDS  faired  in  comparison  to  the 
best  performance  of  the  CCSDS  protocol  in  the  95-4-1  simulation  model.  Due  to  the 
increase  in  transfer  frame  header  size,  the  CCSDS  configuration  used  in  the  "ATM- 
version"  was  a  transfer  frame  payload  length  of  198  bytes,  a  source  packet  payload  length 
of  192  bytes,  and  Reed-Solomon  encoding  OFF.  The  CCSDS  configuration  used  for  the 
comparison  was  a  transfer  frame  payload  length  of  1000  bytes,  a  source  packet  payload 
Length  of  2000  bytes,  and  Reed-Solomon  encoding  OFF.  This  configuration  was  chosen 
because  it  produced  the  best  compromise  between  throughput  and  data  quality  in  the  95- 
4-1  simulation  model.  These  results  are  similar  to  those  obtained  during  the  88-10-2 
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simulation  sequence  and  the  flight  test.  Again,  these  results  suggest  further  exploration 
of  using  ATM,  or  an  ATM-CCSDS  hybrid,  in  the  DoD  test  range  community. 


Contour  Plot  of  Throughput  and  Data  Quality 
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Figure  34.  Contour  Plot  of  Combined  Performance  Using  the  95-4-1  Channel  Model 


Table  10.  Comparison  of  ATM  and  CCSDS  Using  the  95-4-1  Simulation  Model 


Protocol 

Transfer  Frame 
Payload  Length 
(Bytes) 

Source  Packet  Payload 
Length  (Bytes) 

Data 

Quality  (%) 

Throughput 

(Bps) 

CCSDS 

1000 

2000 

94.48 

116,610 

ATM 

198 

192 

93.37 

107,890 

Percent  Difference  = 

-1.17% 

-7.48% 
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6.8  Flight  Test  Conclusions  ancl  Recommendations 


The  Consultative  Committee  for  Space  Data  Systems  (CCSDS)  packet  telemetry 
recommendation  was  successfully  evaluated  for  use  in  the  Department  of  Defense  (DoD) 
test  range  environment.  The  effect  of  transfer  frame  length,  source  packet  length,  and 
Reed-Solomon  encoding  on  throughput  and  data  quality  were  determined.  In  general, 
test  results  agreed  with  simulation  model  predictions.  In  addition,  sufficient  data  was 
collected  to  compare  CCSDS  and  ATM  performance.  All  objectives  were  met. 

Effective  throughput  is  dependent  on  transfer  frame  length,  source  packet  length, 
and  Reed-Solomon  encoding.  In  general,  throughput  increased  with  transfer  frame  length 
until  a  transfer  frame  length  of  800  bytes,  at  which  point  throughput  began  to  drop  off. 
Throughput  performance  was  the  highest  for  source  packet  payload  lengths  between  200 
and  2000  bytes,  but  fell  off  for  payload  lengths  below  200  bytes  and  above  2000  bytes. 
Throughput  performance  overall  was  lower  when  Reed-Solomon  encoding  was  used. 

The  configuration  of  CCSDS  parameters  that  yielded  the  best  throughput  performance 
was  a  transfer  frame  length  of  800  bytes,  source  packet  length  of  500  bytes,  and  Reed- 
Solomon  encoding  OFF. 

1.  Reed-Solomon  encoding  should  be  off  for  maximum  throughput  performance. 

2.  A  transfer  frame  length  of  800  bytes,  source  packet  length  of  500  bytes,  and  Reed- 

Solomon  encoding  off  should  be  used  to  obtain  maximum  throughput. 

Data  quality  was  dependent  on  source  packet  length  and  Reed-Solomon  encoding. 
The  data  collected  demonstrated  negligible  correlation  between  transfer  frame  length  and 
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data  quality.  Data  quality  decreased  with  increasing  source  packet  length,  with  a 
maximum  average  data  quality  of  97.1%  occurring  at  194  bytes.  Due  to  limitations 
imposed  by  the  CCSDS  implementation  software,  Reed- Solomon  encoding  was  only 
tested  with  a  transfer  frame  payload  length  of  939  bytes.  The  collected  data  indicated 
that  Reed- Solomon  encoding  may  decrease  data  quality,  rather  than  increasing  it  as 
predicted  by  modeling  and  simulation.  This  restriction  precluded  an  in-depth  evaluation 
of  the  effects  of  Reed-Solomon  encoding  on  data  quality. 

3.  Effects  of  Reed-Solomon  encoding  on  data  quality  with  the  transfer  frame  length 
restriction  removed  should  be  investigated. 

4.  A  source  packet  length  of  194  bytes  with  Reed-Solomon  encoding  off  should  be 
used  to  obtain  maximum  data  quality. 

Both  the  ANOVA  and  contour  plot  analysis  suggested  that  the  best  throughput 
and  data  quality  combination  occurred  with  a  transfer  frame  length  of  800  bytes  and 
source  packet  length  of  500  bytes.  Analysis  of  the  combined  data  indicated  that  the 
optimum  combination  was  achieved  with  Reed-Solomon  encoding  OFF. 

5.  A  transfer  frame  length  of  800  bytes  and  source  packet  length  of  500  bytes  with 
Reed-Solomon  encoding  off  should  be  used  to  obtain  an  optimum  combination  of 
throughput  and  data  quality. 

CCSDS  and  ATM  protocol  performance  was  compared.  Overall,  data  quality  and 
throughput  performance  using  the  ATM  protocol  was  sufficiently  close  to  that  of 
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CCSDS.  Data  quality  between  the  two  protocols  was  not  significantly  different. 
Throughput  performance  was  6.47%  higher  using  CCSDS. 


6.  Further  exploration  of  using  the  ATM  protocol  in  the  DoD  test  environment 
should  be  accomplished. 


Results  of  the  flight  testing  are  summarized  in  Table  11  below. 


Table  11.  Summary  of  Flight  Test  Results 


Priority  Level  of  Mission 
Requirements 

Reed- 

Solomon 

(on/off) 

TF  Payload 

SP  Payload 

Best  Performing 

Throughput 

Length  (Bytes) 

Length  (Bytes) 

Configuration 

100% 

0% 

ON 

Not  Recommended 

RS:  OFF 

TF:  800 

SP:  500 

OFF 

800 

200  -  2000 

50% 

50% 

ON 

Not  Recommended 

RS:  NO 

TF:  800 

SP:  500 

OFF 

800 

200  -  500 

0% 

100% 

ON 

Not  Recommended 

RS:  OFF 

TF:  800 

SP:  194 

OFF 

Any 

194 

100 


CHAPTER  VII  -  OVERALL  CONCLUSIONS  &  RECOMMENDATIONS 


7.1  Conclusions 

This  research  evaluated  the  practical  use  of  the  CCSDS  packet  telemetry  protocol 
in  the  DoD  test  range  environment  and  established  general  guidance  for  maximizing  the 
performance  of  the  protocol  according  to  mission  requirements.  Following  successful 
simulation  and  analysis  using  network  simulation  software  and  a  synthesized  channel 
model  based  on  previous  flight  test  results,  the  CCSDS  protocol  was  evaluated  and  the 
simulation  results  validated  during  flight  test  at  Edwards  AFB,  CA.  Finally  the 
simulation  channel  model  was  modified  to  more  accurately  duplicate  the  channel  error 
encountered  during  flight  test.  Using  this  updated  model,  the  simulations  were  rerun  in 
an  attempt  to  remove  channel  BER  as  a  variable  differentiating  the  flight  test  and 
simulation  results.  Table  12  and  Table  13  below  summarize  the  overall  results  of  this 
work. 

The  flight  test  results  generally  agreed  with  the  modeling  and  simulation  results. 
With  regards  to  throughput,  both  the  simulation  and  flight  test  results  indicated  that 
throughput  generally  increases  as  transfer  frame  length  increases,  and  that  Reed- Solomon 
should  be  OFF  to  achieve  higher  throughput  rates.  This  intuitively  makes  sense  since  a 
higher  data-to-overhead  ratio  should  produce  higher  throughput  rates. 

Along  the  same  lines,  the  better  the  channel  (i.e.,  lower  BER),  the  greater  the 
number  and  size  of  source  packets  that  should  be  able  to  successfully  make  it  through  the 
channel.  The  more  that  make  it  through,  the  higher  the  resulting  throughput  should  be. 
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Table  12.  Overall  Summary  of  Research  Results 


Priority  Level  of 
Mission  Rqmts 

Simulation  (88- 10-2  Channel  Model)1 1 

Flight  Test12 

Simulation  (95-4- 1  Channel  Model)12 

Through¬ 

put 

Data 

Quality 

RS 

TF 

Payload 

Length 

(Bytes) 

SP 

Payload 

Length 

(Bytes) 

Best  Performing 
Configurations 

RS 

TF 

Payload 

Length 

(Bytes) 

SP 

Payload 

Length 

(Bytes) 

Best 

Performing 

Configurations 

RS 

TF 

Payload 

Length 

(Bytes) 

SP 

Payload 

Length 

(Bytes) 

Best  Performing 
Configurations 

100% 

0% 

ON 

Not  Recommended 

RS:  OFF 

TF:  1000 

SP:  1000 

ON 

Not  Recommended 

RS:  OFF 

TF:  800 

SP:  500 

ON 

Not  Recommended 

RS:  OFF 

TF:  1000 

SP:  2000 

OFF 

600- 

1000 

OFF 

800 

200- 

2000 

OFF 

600- 

1000 

500- 

6000 

50% 

50% 

ON 

Not  Recommended 

RS:  OFF 

TF:  1000 

SP:  1000 

ON 

Not  Recommended 

RS:  OFF 

TF:  800 

SP:  500 

ON 

Not  Recommended 

RS:  OFF 

TF:  1000 

SP:  2000 

OFF 

600- 

1000 

500- 

1400 

OFF 

800 

200- 

500 

OFF 

600- 

1000 

500- 

6000 

0% 

100% 

ON 

Any 

KTjTjS 

RS:  ON 
TF:  1000 
SP:  1400 

RS:  OFF 
TF:  1000 
SP:  1000 

ON 

Not  Recommended 

RS:  OFF 

TF:  800 

SP:  194 

ON 

Any 

500- 

6000 

RS:  ON 
TF:  1000 
SP:  2000 

RS:  OFF 
TF:  1000 
SP:  2000 

OFF 

Any 

500- 

2000 

OFF 

Any 

194 

OFF 

Any 

500- 

6000 

1 1  Data  quality  and  throughput  values  based  on  a  channel  profile  of  approximately  88%  error-free 
activity 

12  Data  quality  and  throughput  values  based  on  a  channel  profile  of  approximately  95%  error- free 
activity 

i  o 

Data  quality  and  throughput  values  based  on  a  channel  profile  of  approximately  95%  error-free 
activity 


activity,  10%  cluster-error  activity,  and  2%  burst-error 
activity,  4%  cluster-error  activity,  and  1%  burst-error 
activity,  4%  cluster-error  activity,  and  1%  burst-error 


Table  13.  Overall  Results  of  ATM/CCSDS  Comparison 


Simulation  (88-10-2 
Channel  Model)14 

Flight  Test15 

Simulation  (95-4- 1 
Channel  Model)16 

Protocol 

Data 

Quality 

(%) 

Throughput 

(Bps) 

Data 

Quality 

(%) 

Throughput 

(Bps) 

Data 

Quality 

(%) 

Throughput 

(Bps) 

CCSDS 

87.83 

108,360.00 

97.1 

115,357 

94.48 

116,610 

ATM 

87.70 

101,572.76 

96.9 

107,899 

93.37 

107,890 

Percent 
Difference  = 

-0.15% 

-6.26% 

-0.21% 

-6.47% 

-1.17% 

-7.48% 

The  simulation  and  flight  test  results  corroborated  this  hypothesis.  In  the  worst  channel 
(i.e.,  highest  BER)  tested,  the  88-10-2  simulation  model,  throughput  was  highest  for 
source  packet  payload  lengths  in  the  range  of  500  to  2000  bytes.  The  next  best  channel 
tested  was  the  test  range  at  Edwards  AFB,  where  the  channel  followed  an  approximate 
95-4- 1  error  breakdown  but  also  included  dynamic  elements  of  error  due  to  atmosphere, 
weather,  antenna  patterns,  etc.  As  expected,  data  from  testing  in  this  channel  indicated 
that  throughput  was  the  highest  for  a  slightly  wider  range  of  source  packet  lengths, 
namely  200  to  2000  bytes.  Finally  in  the  channel  model  that  was  the  best  (i.e.,  lowest 
BER),  the  95-4-1  simulation  model,  where  the  dynamic  elements  of  error  were  not 
explicitly  included,  the  range  of  source  packet  payload  lengths  producing  the  highest 
throughput  was  the  largest,  500-6000  bytes. 


14  Data  quality  and  throughput  values  based  on  a  channel  profile  of  approximately  88%  error- free  activity, 
10%  cluster-error  activity,  and  2%  burst-error  activity 

15  Data  quality  and  throughput  values  based  on  a  channel  profile  of  approximately  95%  error- free  activity, 
4%  cluster-error  activity,  and  1%  burst-error  activity 

16  Data  quality  and  throughput  values  based  on  a  channel  profile  of  approximately  95%  error- free  activity, 
4%  cluster-error  activity,  and  1%  burst-error  activity 
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In  the  analysis  of  data  quality  performance,  both  the  simulation  and  flight  test 
results  suggested  that  transfer  frame  length  is  not  a  factor  in  determining  data  quality. 
When  the  Edwards  AFB  channel  is  good,  it  is  virtually  error- free.  When  the  channel  is 
bad,  the  probability  of  error  was  typically  so  high  (e.g.,  during  a  cluster  error  the 
probability  of  a  bit  error  was  approximately  0.5)  that  even  the  smallest  transfer  frames 
will  probably  not  make  it  through.  In  addition,  the  actual  data  is  packed  into  the  source 
packets.  So  whether  a  transfer  frame  survives  or  not  is  not  as  important  as  whether  the 
source  packet,  which  may  be  divided  among  numerous  transfer  frames,  makes  it  to  the 
ground.  Given  this  channel  behavior,  it  was  not  surprising  that  transfer  frame  length  did 
not  play  a  big  role  in  determining  data  quality. 

Source  packet  length,  however,  did  play  a  significant  role  in  determining  data 
quality.  It  was  expected,  given  the  channel  BER,  that  smaller  source  packets  would  yield 
the  best  data  quality.  Since  even  a  single  byte  error  in  a  source  packet  could  result  in  the 
entire  source  packet  being  deemed  "bad",  a  long  source  packet  being  lost  would  result  in 
a  large  amount  of  data  also  being  lost.  Smaller  source  packets  on  the  other  hand,  would 
allow  less  data  to  be  lost  during  a  short  error  burst  or  cluster.  The  flight  test  results 
confirmed  this  prediction.  A  source  packet  length  of  194  bytes  yielded  the  best  data 
quality.  As  the  size  of  the  source  packet  was  decreased  below  194  bytes,  problems  with 
the  computer  equipment  being  able  to  generate  and  process  the  large  number  of  source 
packets  necessary  to  maintain  the  channel  data  rate  came  into  play  and  actually  began  to 
decrease  data  quality.  The  88-10-2  and  95-4-1  simulation  results  found  that  a  wider 
range  of  source  packet  payload  lengths  could  produce  high  data  quality,  500-2000  bytes 
and  500-6000  bytes,  respectively.  Considering  that  the  maximum  source  packet  length  is 
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65,542  bytes,  these  ranges  are  still  on  the  low  end  of  possible  source  packet  lengths.  The 
differences  between  the  flight  test  and  simulation  results  are  most  likely  due  to  real-world 
factors  not  explicitly  incorporated  into  the  simulation  models,  such  as  aircraft  flight  path 
relative  to  the  ground  station. 

There  was  some  discrepancy  between  the  simulation  and  flight  test  results  with 
regards  to  the  use  of  Reed-Solomon  to  improve  data  quality.  The  simulations  identified  a 
very  slight  (less  than  2%)  advantage  to  using  Reed-Solomon  whereas  the  flight  tests  did 
not  (data  quality  fell  up  to  4.4%  using  Reed-Solomon).  The  main  reason  for  this 
difference  may  be  that  the  data  collected  during  flight  testing  with  Reed-Solomon  ON 
was  extremely  limited.  As  described  in  previous  chapters,  the  software  used  to 
implement  CCSDS  during  the  flight  test  limited  transfer  frame  payload  length  to  a  single 
length  of  939  bytes  when  Reed-Solomon  was  ON.  Although  results  showed  that  transfer 
frame  length  was  not  a  significant  factor  in  determining  data  quality,  it  limited  the 
amount  of  data  collected  with  Reed-Solomon  ON  compared  to  that  collected  with  Reed- 
Solomon  OFF.  Regardless,  even  in  the  simulator,  the  advantages  gained  using  Reed- 
Solomon  were  small,  suggesting  that  the  possible  data  quality  improvements  using  Reed- 
Solomon  may  not  be  worth  the  effort  to  configure  software  and  equipment  to  implement 
CCSDS  with  Reed-Solomon  encoding,  particularly  since  both  simulation  and  flight  test 
results  suggested  that  Reed-Solomon  significantly  degrades  throughput  (up  to  12%  in  the 
simulation  results). 

The  CCSDS  configurations  yielding  the  best  compromise  between  throughput  and 
data  quality  were  derived  directly  from  the  individual  throughput  and  data  quality  results 
described  above.  In  general,  both  the  simulation  and  flight  test  results  suggested  that  the 
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CCSDS  configuration  that  maximized  throughput  also  provided  the  best  tradeoff  between 
throughput  and  data  quality.  This  analysis  is  described  in  depth  in  Chapters  IV  and  VI. 

Finally  a  comparison  of  the  ATM  and  CCSDS  protocols  was  performed  as  a 
precursor  to  future  work  towards  using  the  ATM  protocol  in  the  test  range  community  in 
conjunction  with,  or  instead  of,  the  CCSDS  protocol.  Overall,  the  performance  of  the 
ATM  protocol  was  sufficiently  close  to  that  of  CCSDS  to  warrant  further  investigation. 
Both  the  simulation  and  flight  test  results  yielded  similar  results.  Averaging  the  three 
sets  of  results,  throughput  attained  using  the  ATM-version  was  6.74%  lower  than  that 
with  CCSDS  and  data  quality  was  0.51%  lower.  While  the  throughput  performance  of 
the  ATM  protocol  was  lower  than  that  of  CCSDS  in  this  study,  the  results  were  "close 
enough"  that  with  further  "tuning"  the  ATM  protocol  may  be  able  to  offer  comparable 
throughput  performance. 

7.2  Recommendations 

This  research  has  mapped  the  relationships  between  the  primary  CCSDS 
parameters  (transfer  frame  length,  source  packet  length,  and  Reed- Solomon  encoding) 
and  the  resulting  protocol  performance  (measured  in  terms  of  throughput  and  data 
quality).  It  has  also  provided  guidance  with  regards  to  optimizing  use  of  the  protocol  to 
meet  mission- specific  requirements.  The  results  of  this  research  should  suffice  for 
meeting  the  basic  needs  of  the  test  community  for  configuring  equipment  for  telemetry 
data  transmission.  Further  investigation  of  using  the  ATM  protocol  in  the  test  range 
environment  is  highly  recommended,  alone  or  in  conjunction  with  the  CCSDS  protocol. 
To  facilitate  that  work  it  would  be  beneficial  to  enhance  the  OPNET  simulation  model  to 
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explicitly  include  the  effects  of  dynamic  environmental  variables.  While  the  difference 
those  real-world  variables  made  to  this  research  effort  was  relatively  minor,  an  in-depth 
investigation  of  an  ATM-CCSDS -hybrid- protocol  would  benefit  from  a  more  robust 
model  of  channel  behavior. 

The  CCSDS  packet  telemetry  protocol  clearly  merits  use  in  the  DoD  test  range 
community.  With  further  optimization,  and  possible  fusion  with  the  ATM  protocol,  it 
may  prove  to  be  the  key  to  meeting  DoD  telemetry  system  requirements  at  test  ranges 
around  the  country. 
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APPENDIX  A  -  OPNET  Model  Design 


A.1  OPNET  Model 

OPNET  is  a  modeling  and  simulation  tool  that  provides  an  environment  for 
analysis  of  communication  networks.  It  defines  a  model  using  a  three- layer  hierarchical 
structure.  The  highest  layer,  referred  to  as  the  network  layer,  is  where  the  network 
topology  is  defined.  In  the  second  layer,  called  the  node  layer,  the  internal  structure  and 
behavior  of  each  node  in  the  network  model  is  defined.  Finally,  the  process  layer 
specifies  logic  or  control  flow  among  components  in  the  form  of  a  finite  state  machine. 

The  N-source  network  topology  used  for  the  design  and  development  of  the 
packet  telemetry  system  model  is  shown  in  Figure  35.  Source  and  destination  end- 
systems  are  connected  to  a  pair  of  switches  that  communicate  via  a  point-to-point  link. 
The  figure  also  shows  node  models  for  the  airborne  and  ground  switches,  as  well  as  the 
on-board  data  sources.  The  node  architecture  for  the  on-board  data  sources  consists  of  N 
data  sources  modeled  as  one  "large"  data  source.  The  underlying  process  model  is 
responsible  for  producing  source  packets  and  organizing  them  into  data  segments  for 
subsequent  insertion  into  a  transfer  frame.  The  node  architecture  for  the  airborne  switch 
(Switch  1)  consists  of  a  single  processor  responsible  for  completing  the  construction  of 
transfer  frames,  including  insertion  of  transfer  frame  idle  data  if  necessary,  and  managing 
the  transmission  of  transfer  frames  off  the  aircraft  in  such  a  way  as  to  maintain  the  1 
Mbps  channel  data  rate.  The  node  architecture  for  the  ground  switch  (Switch  2)  consists 
of  a  single  point-to-point  receiver  to  capture  the  incoming  transfer  frames  and  a  processor 
to  reconstruct  the  source  packets. 
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Figure  35.  The  OPNET  Model 


The  packet  telemetry  system  is  modeled  in  OPNET  using  a  point-to-point  wired 
connection  rather  than  a  wireless  model.  Although  OPNET  is  capable  of  modeling  a 
wireless  environment,  doing  so  adds  unnecessary  complexity  to  the  model/simulation. 
For  example,  the  transfer  of  telemetry  data  involves  only  one  source  node  (the  aircraft) 
and  one  destination  node  (the  ground  station).  A  typical  wireless  network,  on  the  other 
hand,  consists  of  multiple  sources  and  multiple  receivers,  where  each  receiver  can 
potentially  receive  every  packet  that  is  broadcast.  In  addition,  terrain,  elevation,  and 
antenna  placement  effects  on  radio  propagation  and  signal  attenuation  are  accounted  for 
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in  the  channel  link  model,  making  the  use  of  OPNET's  terrain  modeling  module  (part  of 
the  wireless  model)  superfluous.  For  these  reasons,  OPNET's  wireless  model  is  not 
used. 

Source  packets  are  produced  by  on-board  data  sources.  These  source  packets  are 
segmented  into  transfer  frames  and  transmitted  over  the  physical  medium.  The 
segmentation  of  source  packets  and  subsequent  transmission  of  transfer  frames  are 
represented  by  the  Source  and  Transmitter  process  models,  respectively.  The  OPNET 
process  modeling  methodology  [16]  was  used  in  the  development  of  the  Source  and 
Transmitter  process  models.  The  key  steps  in  this  modeling  methodology  include: 
definition  of  system  context,  process  level  decomposition,  enumeration  of  events  (per 
process),  state-level  decomposition  (per  process),  construction  of  an  event  response  table 
(per  process),  and  construction  of  the  finite  state  machine  (per  process).  This 
development  of  the  OPNET  Source  and  Transmitter  process  models  is  described  in 
Appendix  B. 

A. 2  Segmentation  and  Reassembly  Buffer 

The  process  of  organizing  source  packets  into  transfer  frames  on  the  aircraft  and 
later  reassembling  the  source  packets  from  the  transfer  frames  received  on  the  ground 
was  done  using  two  specialized  buffers.  The  first,  a  segmentation  buffer,  was  used  in  the 
airborne  portion  of  the  model.  Each  newly  created  source  packet  was  put  into  one  end  of 
the  segmentation  buffer.  Segments  of  a  designated  length  could  then  be  pulled  out  the 
other  end  of  the  buffer  in  a  first- in- first-out  manner.  The  length  of  the  segment  pulled  out 
was  equal  to  the  length  of  the  data  field  of  the  transfer  frame  being  tested.  Segments 
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were  padded  to  the  requested  size  with  transfer  frame  idle  data  if  necessary.  Transfer 
frame  header  and  synchronization  bytes  were  then  added  to  the  data  segment  and  the 
completed  transfer  frame  sent  through  the  channel.  On  the  receiving  end,  a  reassembly 
buffer  was  used.  As  transfer  frames  arrived  on  the  ground,  the  header  and 
synchronization  bytes  were  stripped  away  and  the  remaining  data  segment  put  into  the 
reassembly  buffer.  A  specialized  OPNET  Kernel  Procedure  was  then  used  to  reassemble 
the  data  in  the  reassembly  buffer  back  into  the  original  source  packets.  Completely 
reassembled  source  packets  were  removed  from  the  buffer  when  available  and  statistical 
information  recorded  (e.g.,  end-to-end  delay)  for  use  in  the  final  CCSDS  analysis.  To 
maintain  the  1  Mbps  channel  data  rate,  "idle"  transfer  frames  were  created  and  sent 
through  the  channel  if  the  segmentation  buffer  was  empty  at  the  time  a  transfer  frame  was 
needed.  These  idle  transfer  frames  were  identified  using  an  arbitrary  "0001" 
synchronization  pattern.  Once  received  on  the  ground,  idle  transfer  frames  were 
identified  and  destroyed  instead  of  being  placed  in  the  reassembly  buffer. 

A. 3  Channel  Characterization 

To  emulate  the  bursty- error  behavior  of  the  downlink  channel,  a  custom-designed 
link  model  was  used  to  connect  Switch  1  and  Switch  2.  Numerous  efforts  have  been 
made  to  measure  bit  error  performance  of  aeronautical  telemetry  links.  Picking  one 
channel  characterization  is  highly  problematic  since  there  is  no  single  air-to-ground 
channel  scenario.  Flight  profile,  weather,  vehicle  speed  ranges,  antenna  type  and 
placement,  and  local  terrain  are  all  uncontrolled  variables  that  significantly  influence 
channel  characteristics. 
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Despite  these  difficulties,  flight  tests  conducted  by  the  ARTM  project  office  have 
confirmed  the  two  primary  sources  of  bit  errors  and  short-term  link  failures  in  the 

1  n 

traditional  test  corridors  at  Edwards  AFB  are  "error  bursts"  and  "error  clusters".  An 
error  burst  is  a  sporadic,  impulse-type  event,  where  the  bit  error  probability  (BEP) 
suddenly  degrades  to  the  range  of  10"  to  10"  .  The  duration  of  error  bursts  (at  T-39 
speeds  over  the  baseline  corridors)  is  in  the  range  of  a  few  hundred  milliseconds  (msec) 
to  one  second.  The  second  type  of  error,  an  error  cluster,  occurs  more  frequently  and  is 
associated  with  strong,  two -ray,  frequency  selective  fades.  They  are  primarily  seen  when 
the  receiving  antenna  main  lobe  grazes  the  ground  or  horizon.  BEP  values  during  an 
error  cluster  are  approximately  0.5.  In  reality,  the  receiver/detector  has  lost 
synchronization- -the  link  is  broken.  The  link  model  used  in  the  OPNET  design  was  built 
to  emulate  the  real-  world  channel  behavior  as  closely  as  possible.  This  is  further 
described  in  the  next  section. 

A. 4  Three-State  Channel  Model 

Errors  on  digital  telemetry  transmission  systems  are  known  to  be  bursty  in  nature. 
Hence,  models  that  treat  the  channel  as  being  memoryless  do  not  adequately  represent  its 
error  performance.  In  this  study,  a  three- state  Markov  chain  is  used  to  model  the  bursty- 
error  characteristics  of  the  channel  [21].  This  type  of  model  was  first  proposed  by 
Gilbert.  According  to  the  original  two- state  Gilbert  model,  at  any  instant  in  time  the 
channel  is  assumed  to  be  in  either  one  of  two  states.  This  is  shown  in  Figure  36.  In  the 

1 7  The  ARTM  project  used  four  of  the  traditional  test  corridors  at  Edwards  AFB,  however  the  most  useful 
(repeatable)  baseline  link  performance  data  was  obtained  from  three--"Cords  Road",  "Black  Mountain”, 
and  one  of  the  high  altitude  supersonic  corridors. 
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1  9 

good  state,  G,  the  probability  of  error  is  so  small,  10“  ,  that  it  is  assumed  to  be  zero.  In 
the  bad  state,  B ,  errors  occur  with  probability  1  -  h  where  h  is  the  probability  of  no  bit 
error.  The  duration  of  each  state  is  expressed  in  terms  of  transition  probabilities.  A 
transition  from  G  to  B  occurs  with  probability  P  and  a  transition  from  B  to  G  with 
probability  p.  The  model  remains  in  state  G  with  probability  Q  =  \  -  P.  and  remains  in 
state  B  with  probability  q  =  1  -  p. 


From  ARTM's  work  to  characterize  the  telemetry  link  it  is  known  that  two  types 
of  errors  can  occur  -  error  clusters  and  error  bursts.  Although  it  is  difficult  to  precisely 
quantify  the  channel  behavior,  for  the  purposes  of  this  research  only  an  approximate  level 
of  accuracy  is  required.  Table  14  summarizes  the  channel  profile  that  was  used.  These 
values  are  based  on  "typical"  results  from  ARTM  flight  tests. 


Table  14.  Channel  Profile 


State 

Percentage  of  time  spent  in  state  (%) 

BEP 

Duration  (msec) 

Error- free 

88 

0 

variable 

Error-cluster 

10 

0.5 

100-1000 

Error-burst 

2 

fTUffH 

200 
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To  reflect  the  distinctive  behavior  of  the  two  types  of  error  activity,  the  two-state 


Gilbert  model  is  expanded  to  a  three- state  variation.  This  is  shown  in  Figure  37.  In  this 
model,  Pc  and  Pi,  are  the  probabilities  of  transitioning  from  the  good  state,  G,  to  the  bad 
states  B ciuster  and  Bhurst,  respectively.  Q ,  qc,  and  qh  are  the  probabilities  of  staying  in  G, 
Bduster,  and  Bhurst,  while  pc  and  pt,  are  the  probabilities  of  transitioning  from  the  Bciuster  and 
Bimrst  states  back  to  G. 


Figure  37.  Three-State  Channel  Model 


The  probability  of  a  state  transition  in  the  three- state  model  is  evaluated  based  on 
elapsed  time.  The  time  spent  in  each  of  the  three  states  is  modeled  as  an  exponentially 
distributed  random  variable  with  different  means.  This  time  modulated  approach 
significantly  reduces  the  computational  burden  inherent  in  schemes  that  evaluate  state 
transitions  on  a  bit-by-bit  basis. 

To  reflect  the  channel  profile  (Table  14)  as  closely  as  possible,  the  byte  error 
probabilities  and  mean  duration  times  shown  in  Table  15  were  chosen  for  the  OPNET 
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link  model  used  to  connect  Switch  1  and  Switch  2.  In  the  error-burst  state,  the  bit-error 


probability  is  randomly  chosen  each  time  the  state  is  entered  from  the  three  values 
shown.  These  values  correspond  to  10‘3,  104,  and  10" 5  respectively.  In  the  error-cluster 
state,  the  mean  duration  is  chosen  randomly  each  time  the  state  is  entered  from  the  values 
shown.  These  values  were  chosen  to  emulate  the  100-1000  msec  range  in  the  ARTM 
data  and  at  the  same  time  achieve  the  88,  10,  2%  breakdown  of  time  spent  in  each  state. 
Similarly,  the  mean  duration  in  the  error- free  state  is  chosen  randomly  from  the  values 
shown  in  the  table.  These  times  were  derived  from  a  sample  bit-error  mask  provided  by 
the  ARTM  office.  The  repetition  of  some  values  is  done  to  increase  their  probabilistic 
weighting  during  the  random  selection.  This  is  done  to  mirror  the  frequency  of 
occurrence  of  these  times  in  the  provided  sample  error  mask,  while  at  the  same  time 
achieve  the  88,  10,  2%  breakdown  of  time  spent  in  each  state. 


Table  15.  Channel  Model  Values  Used  in  OPNET  Model 


State 

- rn - 

Byte  Error  Probabilities 

Mean  Time  in  State  (sec) 

Error- free  (G) 

0 

26,3.3,3.3,0.6,  0.6,  0.6,  0.6, 
0.08,  0.08,  0.05,  0.05 

Error-cluster  (BciUster) 

0.9961 

1.0,  0.4,  0.1 

Error-burst  (Bburst) 

0.007972055,  0.00079972, 
0.000079997 

0.2 

A.  5  Conversion  From  Bits  to  Bytes 

The  CCSDS  packet  telemetry  protocol  uses  an  optional  16  Reed- Solomon  byte 

error  correction  capability.  This  encoding  scheme  can  correct  up  to  16  Reed-Solomon 

byte  errors  in  each  codeword,  where  one  codeword  is  223  bytes  in  length.  Translating 

this  into  OPNET  terminology,  when  Reed-Solomon  encoding  is  used,  the  error  correction 

18  The  values  in  this  column  represent  Byte  Error  Probabilities  derived  from  the  Bit  Error  Probabilities 
provided  by  ARTM. 


115 


threshold  is  16  bytes  for  every  block  of  223  transmitted  bytes.  When  a  codeword  is 
received,  the  number  of  byte-errors  in  that  codeword  is  calculated.  If  more  than  16  byte- 
errors  have  occurred,  the  codeword  is  marked  as  "bad".  Otherwise  the  codeword  is 
accepted  as  being  "good".  The  CCSDS  protocol  transmits  data  in  transfer  frames,  rather 
than  codewords.  Once  received  on  the  ground,  each  transfer  frame  is  decoded  and 
analyzed  for  errors  one  codeword  at  a  time.  To  simplify  error- correction  calculations  in 
the  OPNET  model  used  in  this  research,  the  number  of  byte- errors  is  calculated  for  the 
entire  received  transfer  frame,  rather  than  breaking  it  into  223-byte  codewords,  and  this 
number  compared  to  the  corresponding  multiple  of  16  to  determine  if  the  transfer  frame 
is  accepted  as  "good"  or  "bad".  With  a  byte-error  probability  of  0.9961,  cluster  errors  are 
virtually  equivalent  to  a  total  link  failure.  During  these  times,  byte  errors  are  so 
overwhelming  that  no  codewords,  and  hence  no  transfer  frames,  will  get  through  under 
the  error  threshold.  Since  cluster  errors  make  up  83.33%  of  all  error  behavior, 
simplifying  the  error  calculations  to  the  transfer  frame  level  simplifies  the  model  and 
should  not  greatly  affect  the  total  number  of  "good"  and  "bad"  transfer  frames. 

Typically,  the  OPNET  software  operates  on  data  at  the  bit- level.  From  the  above 
discussion  on  the  correction  of  byte  errors  using  Reed-Solomon,  however,  manipulating 
the  model  data  at  the  byte- level  was  the  more  straightforward  approach.  A  paradigm 
shift  was  in  order.  To  start,  the  channel  data  rate  was  divided  by  eight  to  represent  bytes- 
per- second  (Bps),  rather  than  bits- per- second  (bps).  Each  "OPNET  bit"  could  then  be 
viewed  as  one  byte.  The  existing  C++  code  could  then  be  used  without  any  further 
manipulation  other  than  making  sure  numerical  values  are  stated  in  units  of  bytes  rather 
than  bits. 
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The  bit  error  probability  values  provided  by  the  ARTM  office  were  converted  to 
byte  error  probabilities.  Making  the  simplifying  assumption  that  during  a  period  of  error 
activity,  whether  it  is  an  error  cluster  or  error  burst,  the  bit  errors  are  independent  and 
uniformly  distributed,  the  values  could  be  converted  using  basic  probabilistic  methods. 
This  is  shown  below. 

Let  perr  =  the  probability  that  a  bit  is  in  error 
Then,  the  probability  a  bit  is  not  in  error  is  1  -  pcrr 

o 

The  probability  that  eight  bits  in  a  row  are  all  good  is  (1  -  perr) 

(this  equals  the  probability  of  a  byte  being  received  error  free) 

Thus  the  probability  of  a  single  byte  being  in  error  is  1  -  (1  -  perr) 

So,  the  byte-error-probability  is  1  -  (1  -  perr)s,  where  perr  =  BEP 

The  byte- error  probability  values  shown  in  Table  15  were  calculated  in  this 
manner.  Again,  since  cluster  errors  make  up  83.33%  of  all  error  behavior  and  during  a 
cluster  error  almost  no  bits  make  it  through  unscathed,  making  the  assumption  that  bit 
errors  are  independent  and  uniformly  distributed  simplifies  the  model  and  should  not 
greatly  affect  the  total  number  of  "good"  and  "bad"  transfer  frames  received. 

A. 6  Synchronization  Pattern 

Attached  to  the  beginning  of  each  transfer  frame  is  a  32-bit  frame  synchronization 
marker  used  by  the  receiving  network  to  acquire  synchronization  with  the  frame 
boundaries  after  transmission  through  the  data  channel.  These  sync  bits  are  removed 
before  the  Reed- Solomon  encoding  process.  In  the  OPNET  model,  however,  they  are  not 
removed  and  counted  against  the  16-byte  error  threshold  if  any  bytes  in  the  sync  pattern 
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come  through  the  channel  in  error.  This  simplifying  assumption  was  made  for  three 
reasons.  The  first  reason  for  this  is  that  83.33%  of  the  error  behavior  is  due  to  a  cluster 
error  during  which  virtually  no  transfer  frames  make  it  through  the  channel  under  the 
error  threshold.  Whether  the  sync  bits  are  included  in  the  error  calculations  or  not,  the 
transfer  frame  is  still  very  unlikely  to  be  accepted  as  "good".  Second,  the  sync  bits  make 
up  only  a  small  percentage  of  the  total  bits  transmitted  (as  little  as  0.36%,  and  as  much  as 
21%).  Although  it  is  equally  probable  an  error  could  occur  in  any  one  sync  bit,  the 
likelihood  of  errors  occurring  in  the  synchronization  portion  of  the  transmitted  block 
versus  the  data  portion  of  the  transmitted  block  is  lower  in  most  cases.  Finally,  the  32-bit 
synchronization  pattern  was  selected  because  it  provides  very  good  synchronization 
qualities  in  a  noisy  channel  environment  [6].  Synchronization  is  customarily  confirmed 
at  the  receiving  end  by  making  further  checks  and  when  the  frame  is  of  fixed  length,  as  it 
is  in  the  case  of  CCSDS,  conventional  "flywheeling"  techniques  can  be  used  to  maintain 
frame  synchronization  in  a  noisy  environment  [6].  Thus,  some  of  the  sync  bits  can  be 
lost  to  error  and  synchronization  will  still  be  possible. 

A.  7  Fixed  Propagation  Delay 

In  reality,  the  airborne  transmitter's  distance  from  the  ground  receiver  is  changing 
throughout  the  telemetry  downlink  due  to  altitude  and  position  changes  of  the  aircraft. 
Additionally,  the  altitude/position  profile  of  one  flight  could  vary  greatly  from  that  of 
another  flight.  Modeling  every  case  would  be  as  equally  difficult  as  choosing  one  typical 
case.  Comparing  the  effects  of  distance  on  transfer  frame  and  source  packet  length  is 
beyond  the  scope  of  this  thesis  and  is  left  for  future  study.  A  fixed  propagation  delay  of 
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1.75e-05  seconds  was  used.  This  value  was  based  on  a  traveling  distance  of  3500  meters 
and  traveling  speed  of  ?  c,  where  c  is  the  speed  of  light.  By  fixing  the  propagation  delay, 
the  effects  of  jitter  in  the  received  data  stream  are  not  visible  in  the  simulation  data.  In 
reality,  these  disturbances  in  the  otherwise  constant  data  stream  are  most  likely  slight  and 
easily  overcome  by  the  synchronization  software.  During  cluster  and  burst  errors,  the 
effects  of  jitter  are  all  but  "lost  in  the  weeds". 
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APPENDIX  B  -  OPNET  Model 


B.l  OPNET  Top-Level  and  Node  Models 

The  top  level  of  the  OPNET  model  is  shown  in  Figure  38.  The  Airborne  and 
Ground  nodes  are  shown  in  Figure  39  and  Figure  40,  respectively.  The  remainder  of  the 
appendix  breaks  down  the  design  of  each  process  model  contained  in  these  two  nodes. 


Airborne  Node 


Ground_Node 


Figure  38.  Top  Level  View  of  OPNET  Telemetry  Model 


o  am 

Source_0  Transmitter  pt_0 

Note:  pt_0  is  a  point-to-point  transmitter 

Figure  39.  Airborne_Node  Node  Model 


7=i 

w 

_ 

pr_0 

Sink 

Note:  pr_ 

_0  is  a  point  -to-point  receiver 

Figure  40.  Ground_Node  Node  Model 
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B.2  Process  Model  Development 


B.2.1  Source  Process  Model  Development 

Logical  events  that  can  occur  at  the  Source  include  'start  source  packet  generation, 
'stop  packet  generation',  'packet  generate',  and  'packet  generation  disabled'.  Table  16 
enumerates  the  events  that  can  occur  at  the  Source  and  the  associated  interrupt  types. 


Table  16.  Source  Events 


EVENT 

EVENT  DESCRIPTION 

INTERRUPT 

TYPE 

START 

Indicates  a  start  time  for  packet  generation 
activities 

Self 

STOP 

Indicates  a  stop  time  for  packet  generation 
activities 

Self 

DISABLED 

Packet  source  has  been  disabled 

Self 

PACKET 

GENERATE 

It  is  time  to  generate  the  next  source  packet 

Self 

Table  17  shows  the  state- level  decomposition  of  the  Source  process. 


Table  17.  State -Level  Decomposition  of  Source  Process 


STATE 

NAME 

STATE  DESCRIPTION 

Init 

Initial  State.  Segmentation  and  Reassembly  buffer  is  initialized.  Initialize 
start/stop  times,  statistic  handles,  and  other  miscellaneous  variables 

Generate 

Schedule  PACKET_GENERATE  interrupt  based  on  source  packet 
interarrival  rate 

MakeSP 

Construct  a  source  packet 

Segment 

Insert  source  packet  into  Segmentation  and  Reassembly  buffer 

Stop 

Cancel  generation  of  the  next  source  packet  and  go  into  a  silent  mode 

Table  18  outlines  the  actions  taken  when  an  event  occurs  within  the  Source 
process.  Each  row  of  this  table  represents  a  combination  of  a  state  and  an  event  and  their 
associated  conditions.  The  different  actions  performed  for  each  combination  and  the 
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resulting  next  state  are  listed.  Figure  41  shows  the  state  machine  implementation  for  the 


Source  process  model. 


Table  18.  Source  Event  Respo  nse  Table 


CURRENT 

STATE 

LOGICAL 

EVENT 

CONDITION 

ACTION 

NEXT 

STATE 

Init 

START 

none 

Record  type  of 
interrupt  that  occurred 

Generate 

DISABLED 

none 

Record  type  of 
interrupt  that  occurred 

Stop 

Generate 

PACKET 

GENERATE 

none 

Record  type  of 
interrupt  that  occurred 

MakeSP 

STOP 

none 

Record  type  of 
interrupt  that  occurred 

Stop 

Figure  41.  Source  State  Machine  Implementation 
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B.2.2  Transmitter  Process  Model  Development 
Logical  events  that  can  occur  at  the  Transmitter  include  'start  operations'  and  'send 
frame'.  Table  19  enumerates  the  events  that  can  occur  at  the  Transmitter  and  the 
associated  interrupt  types. 


Table  19.  Transmitter  Events 


EVENT 

EVENT  DESCRIPTION 

INTERRUPT 

TYPE 

START_OP 

The  Segmentation  and  Reassembly  buffer  has  been 
initialized  (by  Source  node).  Begin  accessing  buffer 

Remote 

SEND 

FRAME 

It  is  time  to  send  the  next  transfer  frame 

Self 

Table  20  shows  the  state- level  decomposition  of  the  Transmitter  process. 


Table  20.  State -Level  Decomposition  of  Transmitter  Process 


STATE 

NAME 

STATE  DESCRIPTION 

Initial 

Initial  State.  Calculate  delay  interval  between  transfer  frame  transmissions 

Manager 

Access  Segmentation  and  Reassembly  buffer.  If  a  data  segment  is  available 
in  the  buffer,  remove  it  and  construct  a  transfer  frame.  If  no  data  is 
available  from  the  buffer,  create  an  'idle'  transfer  frame 

Send  TF 

Send  completed  transfer  frame  (actual  or  idle)  to  the  point-to-point 
transmitter  for  transmission  off  the  aircraft 

Table  21  outlines  the  actions  taken  when  an  events  occurs  within  the  Transmitter 
process.  Each  row  of  this  table  represents  a  combination  of  a  state  and  an  event  and  their 
associated  conditions.  The  different  actions  performed  for  each  combination  and  the 
resulting  next  state  are  listed.  Figure  42  shows  the  state  machine  implementation  for  the 
Transmitter  process  model. 
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Table  21.  Transmitter  Event  Response  Table 


CURRENT 

STATE 

LOGICAL 

EVENT 

CONDITION 

ACTION 

NEXT 

STATE 

Initial 

START_OP 

none 

Record  type  of  interrupt 
that  occurred 

Manager 

Send  TF 

SEND_FRAME 

none 

Record  type  of  interrupt 
that  occurred 

Manager 

Figure  42.  Transmitter  State  Machine  Implementation 


B.2.3  Sink  Process  Model  Development 

Logical  events  that  can  occur  at  the  Sink  include  'gnd  arrival'  and  'end  simulation'. 
Table  22  enumerates  the  events  that  can  occur  at  the  Sink  and  the  associated  interrupt 
types. 


Table  22.  Sink  Events 


EVENT 

EVENT  DESCRIPTION 

INTERRUPT 

TYPE 

GND ARRI  V  AL 

The  next  transfer  frame  has  arrived 

Stream 

END_SIMULATION 

Simulation  time  has  expired.  Time  to 
calculate  final  statistics 

Self 

Table  23  shows  the  state- level  decomposition  of  the  Sink  process. 
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Table  23.  State -Level  Decomposition  of  Sink  Process 


STATE 

NAME 

STATE  DESCRIPTION 

Init 

Initial  State.  Create  Reassembly  buffer.  Initialize  variables 

Process 

Determine  if  arriving  transfer  frame  is  good/bad.  If  bad,  discard  and 
collect  statistical  data.  If  good,  unpack  source  packet  segment  and  place 
into  Reassembly  buffer.  Check  for  comple  te  source  packets  in  Reassembly 
buffer.  If  complete  source  packet  available,  remove,  collect  statistical  data, 
then  discard  source  packet 

ENDSIM 

Using  statistical  data  collected  throughout  simulation,  calculate  desired 
performance  metrics  (throughput  and  data  quality).  Output  information  to 
out_file 

Table  24  outlines  the  actions  taken  when  an  events  occurs  within  the  Sink 
process.  Each  row  of  this  table  represents  a  combination  of  a  state  and  an  event  and  their 
associated  conditions.  The  different  actions  performed  for  each  combination  and  the 
resulting  next  state  are  listed.  Figure  43  shows  the  state  machine  implementation  for  the 
Sink  process  model. 


Table  24.  Sink  Event  Response  Table 


CURRENT 

STATE 

LOGICAL 

EVENT 

CONDITION 

ACTION 

NEXT 

STATE 

Process 

GND_ARRIVAL 

none 

Record  type  of 
interrupt  that 
occurred 

Process 

END_S  EMULATION 

none 

Record  type  of 
interrupt  that 
occurred 

ENDSIM 

ENDSIM 

none 

none 

Record  type  of 
interrupt  that 
occurred 

none 
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Figure  43.  Sink  State  Machine  Implementation 


126 


APPENDIX  C  -  Simulation  Length  Calculation 


Rather  than  show  the  simulation  length  calculations  for  all  test  cases,  they  will  be 
shown  here  for  one  case.  Calculations  for  the  other  cases  follow  the  same  procedure. 

Simulation  Length  Calculation: 

Configuration:  Run  =  12 

Transfer  Frame  Payload  Length  =  200  Bytes 
Source  Packet  Payload  Length  =  60000  Bytes 
Source  Packet  Generation  Rate  =  117,920  Bps 

First,  the  throughput  of  each  individual  source  packet  was  recorded  during  a  two- 
minute  preliminary  run.  The  sample  mean  of  the  source  packet  throughput  was 
2986.0223  Bps,  and  the  sample  standard  deviation  was  18,509.8466.  To  get  the 
throughput  accurate  to  within  10%  (roughly  ±18,000  Bps)  at  80%  confidence,  6316 
source  packets  had  to  be  observed  (processed  through  the  system).  This  number  was 
calculated  as  follows: 


The  number  of  observations,  n,  required  to  achieve  ±r%  accuracy  at  an  80% 
confidence  level  is  [12]: 

f  100  7, ?  Y 


where,  x  =  sample  mean 

5  =  sample  standard  deviation 
r  =  desired  accuracy 

z  =  normal  variate  of  the  desired  confidence  level 
Here,  x  =  2986.0233,  5  =  18509.8466,  r=  10,  z=  1-282 
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Substituting,  n  = 


f  100(1. 282)(1 8509.8466) V 


(10)(2986.0233) 

\ 

A  total  of  6316  observations  are  needed. 


=  6315.32 


From  this,  simulation  length  was  determined  to  be  3300  seconds.  This  was 
calculated  based  on  the  time  to  transmit  and  receive  6316  source  packets.  This  is  shown 
below: 


6316  source  packets  x 


60,006  bytes 
source  packet 


1 

1 17920  bytes/ 
/sec 


=  3214.03  seconds 


To  accommodate  other  data  points  with  similar  length  requirements,  simulation 
length  was  set  at  3300  seconds. 
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APPENDIX  D  -  ATM  Equivalent  Calculation 


Given  the  individual  header/overhead  requirements  of  the  ATM  and  CCSDS 
protocols,  it  was  not  possible  to  configure  a  CCSDS  transfer  frame,  and/or  source  packet, 
to  have  48  bytes  of  useful  data  and  five  bytes  of  overhead  as  exists  in  an  ATM  cell.  With 
this  "simple"  solution  not  available,  the  next  best  solution  was  to  conduct  the 
ATM/CCSDS  performance  comparison  using  a  CCSDS  transfer  frame- source  packet 
combination  of  the  same  data- to- overhead  ratio  as  an  ATM  cell,  namely  48:5.  The  result 
was  a  transfer  frame  payload  length  of  179  bytes  and  a  source  packet  payload  length  of 
173  bytes.  The  calculations  used  to  arrive  at  this  result  are  given  below. 

We  want  the  data-to-overhead  ratio  of  the  solution  to  be  48:5.  Another  way  to  look  at  it 
is  we  want  the  fraction  of  overhead  in  the  solution  to  be  5/53. 

Let  x  =  the  number  of  bytes  of  useful  data  in  the  embedded  source  packet 
Overhead  due  to  the  transfer  frame  header  =  8  bytes  (Reed- Solomon  turned  OFF) 
Overhead  due  to  the  source  packet  header  =  6  bytes 
Overhead  due  to  the  synchronization  bytes  =  4  bytes 

The  resulting  equation  is, 

8  +  6  +  4  _  5 
8  +  6  +  4  +  . r  53 
Solving,  x  =  172.8 

Therefore,  the  source  packet  payload  length  was  set  at  173  bytes. 

The  resulting  transfer  frame  payload  length  was  173  bytes  plus  the  six  source  packet 
header  bytes,  or  179  bytes. 
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APPENDIX  E  -  Confidence  and  Accuracy  Calculations 


The  configuration  of  parameters  that  had  the  largest  variance  in  throughput  and 
data  quality  results  was  used  to  calculate  the  reported  confidence  and  accuracies.  This 
was  done  for  both  sets  of  simulations,  as  well  as  the  flight  test. 

The  number  of  replications,  n,  required  to  achieve  ±r%  accuracy  at  a  particular 
confidence  level  is  [12]: 


lOOzs 


\2 


v  ™  j 


where,  x  =  sample  mean 

5  =  sample  standard  deviation 
r  =  desired  accuracy 

z  =  normal  variate  of  the  desired  confidence  level 


Given  the  number  of  replications,  sample  mean,  and  sample  standard  deviation, 
several  confidence  levels  were  inserted  (e.g.,  80%,  90%,  95%,  98%)  and  the  resulting 
accuracies  calculated.  The  highest  confidence  level  producing  satisfactory  accuracy 
levels  for  both  throughput  and  data  quality  was  then  reported.  The  confidence/accuracy 
calculations  are  given  below. 


88-10-2  Simulation  Model: 

CCSDS  configuration  =  (TF  =  400  bytes;  SP  =  1400  bytes;  RS  =  OFF) 

Throughput: 

Given:  n  =  5;  x  =  106,672.00  Bps;  s  =  245.60;  z=  1.645 
Solving,  r  =  0.1694 

Then,  0.1694  x  106,672.00  =  180  — >  So,  throughput  accurate  to  within  ±180  Bps 
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Data  quality: 

Given:  n  =  5;  x  =  88.04%;  s  =  0.2027;  z=  1.645 

Solving,  r  =  0.1694 

Then,  0.1694x88.04  =  0.15 

— >  So,  data  quality  accurate  to  within  ±0.15  percentage  points 
95-4-1  Simulation  Model: 

CCSDS  configuration  =  (TF  =  600  bytes;  SP  =  60,000  bytes;  RS  =  OFF) 

Throughput: 

Given:  n  =  5;  x  =  111,035.74  Bps;  s  =  172.30;  z=  1.645 
Solving,  r  =  0. 1 142 

Then,  0.1142  x  111,035.74  =  127  — >  So,  throughput  accurate  to  within  ±127  Bps 
Data  quality: 

Given:  n  =  5;  x  =  90.67%;  s  =  0.1400;  z=  1.645 

Solving,  r  =  0.1136 

Then,  0.1136x90.67  =  0.103 

— >  So,  data  quality  accurate  to  within  ±0.103  percentage  points 
Flight  Test: 

CCSDS  configuration  =  (TF  =  400  bytes;  SP  =  2000  bytes;  RS  =  OFF) 

Throughput: 

Given:  n  =  4;  x  =  112,662.87  Bps;  s  =  1457.64;  z=  1.282 
Solving,  r  =  0.8290 

Then,  0.8290  x  112,662.87  =  934  — >  So,  throughput  accurate  to  within  ±934  Bps 
Data  quality: 

Given:  n  =  4;  x  =  95.08%;  s=  1.444;  z=  1.282 

Solving,  r  =  0.9735 

Then,  0.9735  x  95.08  =  0.92 

— >  So,  data  quality  accurate  to  within  ±0.92  percentage  points 

Flight  Test  ATM  Data: 

Throughput: 

Given:  n  =  4;  3c  =  107,898.93  Bps;  s  =  2128.77;  z=1.282 
Solving,  r  =  1.788 

Then,  1.788  x  107,898.93  =  1929  — >  So,  throughput  accurate  to  within  ±1929  Bps 
Data  quality: 

Given:  n  =  4;  x  =  96.87%;  s=  1.730;  z=  1.282 

Solving,  r  =  1.619 

Then,  1.619  x  96.87  =  1.57 

— >  So,  data  quality  accurate  to  within  ±1.57  percentage  points 
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APPENDIX  F  -  AN  OVA  Tables 


88-10-2  Simulation 


Throughput: 


Source 

Sum  of 
Squares 

% 

Contribution 

Degrees  of 
Freedom 

Mean 

Square 

F  Value 

Prob  >  F 

Model 

5.759E+01 1 

167 

3.448E+009 

6.664E+005 

<  0.0001 

TF 

2.094E+01 1 

36.4 

5 

4.188E+010 

8.092E+006 

<  0.0001 

SP 

1.199E+01 1 

20.8 

13 

9.227E+009 

1.783E+006 

<  0.0001 

RS 

1.783E+01 1 

31.0 

h  1 

1.783E+01 1 

3.446E+007 

<  0.0001 

TF-SP 

4.531E+009 

0.79 

65 

6.971E+007 

13471.97 

<  0.0001 

TF-RS 

5.889E+010 

10.2 

5 

1.178E+010 

2.276E+006 

<  0.0001 

SP-RS 

3.594E+009 

0.62 

13 

2.764E+008 

53419.75 

<  0.0001 

TF-SP-RS 

1.227E+009 

0.21 

65 

1.888E+007 

3648.64 

<  0.0001 

Pure  Error 

3.477E+006 

0.00060 

672 

5174.79 

Cor  Total 

5.759E+01 1 

839 

•  Where,  TF  =  transfer  frame  payload  length;  SP  =  source  packet  payload  length;  RS  =  Reed- Solomon 
encoding 

•  The  Model  F-value  of  666397.83  implies  there  is  only  a  0.01%  chance  that  a  "Model  F-Value”  this 
large  could  occur  due  to  noise. 

•  Values  of  "Prob  >  F"  less  than  0.0500  indicate  model  terms  are  significant.  In  this  case,  TF,  SP, 
RS,  TF-SP,  TF-RS,  SP-RS,  and  TF-SP-RS  are  significant  model  terms. 


Data  Quality: 


Source 

Sum  of 
Squares 

% 

Contribution 

Degrees  of 
Freedom 

Mean 

Square 

F  Value 

Prob  >  F 

Model 

1.219E+005 

167 

729.72 

1.981E+005 

<  0.0001 

TF 

18.28 

0.015 

5 

3.66 

992.37 

<  0.0001 

SP 

1.21 1E+005 

99.3 

13 

9314.77 

2.528E+006 

<  0.0001 

RS 

181.69 

0.15 

1 

181.69 

49316.89 

<  0.0001 

TF-SP 

311.86 

0.26 

65 

4.80 

1302.29 

<  0.0001 

TF-RS 

86.22 

0.07 

5 

17.24 

4680.68 

<  0.0001 

SP-RS 

57.21 

0.05 

13 

4.40 

1194.45 

<  0.0001 

TF-SP-RS 

116.51 

0.10 

65 

1.79 

486.52 

<  0.0001 

Pure  Error 

2.48 

0.002 

672 

3.684E-003 

Cor  Total 

1.219E+005 

839 

•  Where,  TF  =  transfer  frame  payload  length;  SP  =  source  packet  payload  length;  RS  =  Reed- Solomon 
encoding 

•  The  ModelF-value  of  198071.57  implies  there  is  only  a  0.01%  chance  that  a  "Model  F-Value”  this 
large  could  occur  due  to  noise. 

•  Values  of  "Prob  >  F"  less  than  0.0500  indicate  model  terms  are  significant.  In  this  case,  TF,  SP, 
RS,  TF-SP,  TF-RS,  SP-RS,  and  TF-SP-RS  are  significant  model  terms. 
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Flight  Test 


Throughput: 


Source 

Sum  of 
Squares 

% 

Contribution 

Degrees  of 
Freedom 

Mean 

Square 

F  Value 

Prob  >  F 

Model 

5.982E+009 

40 

1.496E+008 

20.46 

0.1738 

TF 

2.472E+009 

41.3 

5 

4.946E+008 

67.69 

0.0920 

SP 

2.156E+009 

36.0 

5 

4.31 1E+008 

59.00 

0.0985 

RS 

7.322E+008 

12.2 

1 

7.322E+008 

100.19 

0.0634 

TF-SP 

4.403E+008 

7.4 

25 

1.761E+007 

2.41 

0.4747 

TF-RS 

0.000 

0.0 

0 

SP-RS 

3.452E+007 

0.58 

5 

6.904E+006 

0.94 

0.6493 

TF-SP- RS 

0.000 

0.0 

0 

Pure  Error 

7.308E+006 

0.12 

1 

7.308E+006 

Cor  Total 

5.989E+009 

41 

•  Where,  TF  =  transfer  frame  payload  length;  SP  =  source  packet  payload  length;  RS  =  Reed- Solomon 
encoding 

•  The  Model  F-value  of  20.46  implies  there  is  a  17.38%  chance  that  a  "Model  F-Value"  this  large 
could  occur  due  to  noise. 

•  Values  of  "Prob  >  F"  less  than  0.0500  indicate  model  terms  are  significant.  In  this  case  there  are 
no  significant  model  terms. 


Data  Quality: 


Source 

Sum  of 
Squares 

% 

Contribution 

Degrees  of 
Freedom 

Mean 

Square 

F  Value 

Prob  >  F 

Model 

1185.14 

40 

29.63 

103.06 

0.0780 

TF 

81.12 

6.8 

5 

16.22 

56.43 

0.1007 

SP 

771.17 

65.1 

5 

154.23 

536.51 

0.0328 

RS 

0.25 

0.02 

1 

0.25 

0.87 

0.5222 

TF-SP 

285.11 

24.1 

25 

11.40 

39.67 

0.1249 

TF-RS 

0.00 

0.0 

0 

SP-RS 

19.94 

1.7 

5 

3.99 

13.87 

0.2009 

TF-SP- RS 

0.00 

0.0 

0 

Pure  Error 

0.29 

0.02 

1 

0.29 

Cor  Total 

1185.43 

41 

•  Where,  TF  =  transfer  frame  payload  length;  SP  =  source  packet  payload  length;  RS  =  Reed- Solomon 
encoding 

•  The  Model  F-value  of  103.06  implies  there  is  a  7.80%  chance  that  a  "Model  F-Value"  this  large 
could  occur  due  to  noise. 

•  Values  of  "Prob  >  F"  less  than  0.0500  indicate  model  terms  are  significant.  In  this  case,  SP  is  a 
significant  model  term. 
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APPENDIX  G  -  Raw  Simulation  Data  (88-10-2  Channel  Model ) 


This  appendix  lists  the  throughput,  data  quality,  and  channel  utilization  results 
from  each  simulation  run  using  the  88-10-2  channel  model.  Values  shown  are  the 
arithmetic  mean  of  data  from  five  samples.  This  sample  size  yielded  a  worst-case 
confidence  of  90%.  Throughput  data  is  accurate  to  within  ±180  Bps.  Data  quality  data  is 
accurate  to  within  ±0.15  percentage  points.  Confidence  and  accuracy  calculations  are 
shown  in  Appendix  E.  The  following  tables  and  figures  are  provided  in  this  appendix: 

Table  25.  Raw  Experimental  Results  in  Tabular  Form  (Part  1  of  5) 

Table  26.  Raw  Experimental  Results  in  Tabular  Form  (Part  2  of  5) 

Table  27.  Raw  Experimental  Results  in  Tabular  Form  (Part  3  of  5) 

Table  28.  Raw  Experimental  Results  in  Tabular  Form  (Part  4  of  5) 

Table  29.  Raw  Experimental  Results  in  Tabular  Form  (Part  5  of  5) 

Table  30.  Selected  Throughput  Results  Sorted  By  Source  Packet  Payload  Length 

Table  31.  Selected  Throughput  Results  Sorted  By  Transfer  Frame  Length  (Part  1  of  2) 

Table  32.  Selected  Throughput  Results  Sorted  By  Transfer  Frame  Length  (Part  2  of  2) 

Figure  44:  Throughput  Variation  with  Transfer  Frame  Payload  Length 

Figure  45:  Throughput  Variation  with  Source  Packet  Payload  Length 

Table  33.  Selected  Data  Quality  Results  Sorted  By  Source  Packet  Length 

Table  34.  Selected  Data  Quality  Results  Sorted  By  Transfer  Frame  Length  (Part  1  of  2) 

Table  35.  Selected  Data  Quality  Results  Sorted  By  Transfer  Frame  Length  (Part  2  of  2) 

Figure  46.  Data  Quality  Variation  With  Transfer  Frame  Length  In  Graphical  Format 

Figure  47.  Data  Quality  Variation  With  Source  Packet  Length  In  Graphical  Format 
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Table  25.  Raw  Experimental  Results  in  Tabular  Form  (Part  1  of  5) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Fen 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

Initial 

i 

41 

5 

wm 

92865 

35 

39514.29 

42.55 

99.999 

Initial 

wm 

41 

194 

m 

95910 

35 

84006.43 

87.59 

99.994 

Initial 

B 

41 

500 

m 

96390 

35 

85194.28 

88.39 

99.984 

Initial 

Mi 

41 

2000 

m 

96620 

35 

84868.57 

87.88 

99.941 

Initial 

wm 

41 

20000 

m 

96690 

10800 

82803.70 

85.64 

99.998 

Initial 

6 

41 

60000 

m 

96700 

10800 

78900.00 

81.60 

99.994 

Initial 

wm 

200 

5 

@ 

116720 

35 

48070.49 

41.19 

99.995 

Initial 

8 

200 

194 

wm 

116720 

35 

102609.38 

87.91 

99.995 

Initial 

9 

200 

500 

isi 

117520 

35 

103762.88 

88.30 

99.985 

Initial 

m 

200 

2000 

m 

117810 

35 

103588.56 

87.96 

99.947 

Initial 

wm 

200 

20000 

m 

117910 

3300 

101430.30 

86.02 

99.995 

Initial 

EH 

200 

60000 

wm 

117920 

3300 

97530.91 

82.72 

99.985 

Initial 

ra 

400 

5 

m 

120720 

35 

49283.17 

40.83 

99.991 

Initial 

b 

400 

194 

wm 

120720 

35 

105274.38 

87.21 

99.991 

Initial 

wm 

400 

500 

m 

121040 

35 

106471.42 

87.97 

99.981 

Initial 

B 

400 

2000 

wm 

121250 

35 

106422.88 

87.81 

99.944 

Initial 

wa 

400 

20000 

mi 

121350 

3300 

104556.38 

86.16 

99.995 

Initial 

b 

400 

60000 

wm 

121350 

3300 

100290.90 

82.65 

99.985 

Initial 

B 

600 

5 

m 

122110 

35 

49698.43 

40.70 

99.986 

Initial 

El 

600 

194 

m 

122110 

35 

106076.98 

86.87 

99.986 

Initial 

B 

600 

500 

wm 

122110 

35 

107445.70 

88.00 

99.986 

Initial 

600 

2000 

wm 

122440 

35 

107542.88 

87.86 

99.944 

Initial 

El 

600 

20000 

wm 

122540 

3300 

105572.14 

86.15 

99.995 

Initial 

B 

600 

60000 

m 

122540 

3300 

101585.46 

82.91 

99.985 

Initial 

B 

800 

5 

wm 

122820 

35 

49809.97 

40.56 

99.981 

Initial 

800 

194 

wm 

122820 

35 

106272.08 

86.53 

99.981 

Initial 

800 

500 

wm 

122820 

35 

107751.42 

87.74 

99.981 

Initial 

800 

2000 

m 

123040 

35 

107931.44 

87.73 

99.944 

Initial 

800 

20000 

wm 

123140 

3300 

105993.94 

86.08 

99.995 

Initial 

El 

800 

60000 

m 

123150 

3300 

101861.80 

82.72 

99.985 

Initial 

SHi 

1000 

5 

wm 

123250 

35 

49856.57 

40.45 

99.977 

Initial 

1000 

194 

m 

123250 

35 

106389.60 

86.32 

99.977 

Initial 

El 

1000 

500 

wm 

123250 

35 

107951.42 

87.59 

99.977 

Initial 

B 

1000 

2000 

m 

123430 

35 

108022.86 

87.52 

99.931 

Initial 

jgtSa 

1000 

20000 

Mi 

123500 

750 

106213.34 

86.01 

99.977 

Initial 

El 

1000 

60000 

Cl 

123510 

750 

102352.00 

82.92 

99.934 
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Table  26.  Raw  Experimental  Results  in  Tabular  Form  (Part  2  of  5) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Fen 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

Initial 

mm 

41 

5 

mm 

24040 

35 

9936.00 

41.33 

99.995 

Initial 

41 

194 

o 

24240 

35 

21179.26 

87.38 

99.976 

Initial 

41 

500 

m 

24270 

35 

21528.57 

88.75 

99.937 

Initial 

El 

41 

2000 

m 

24285 

35 

21542.86 

88.92 

99.764 

Initial 

m 

41 

20000 

m 

24288 

10800 

20383.33 

83.93 

99.992 

Initial 

El 

41 

60000 

m 

24288 

10800 

18411.11 

75.82 

99.977 

Initial 

m 

200 

5 

mm 

67170 

35 

27633.14 

41.14 

99.992 

Initial 

El 

200 

194 

m 

67170 

35 

58970.46 

87.80 

99.992 

Initial 

mm 

200 

500 

mm 

67432 

35 

60000.00 

88.98 

99.975 

Initial 

El 

200 

2000 

mm 

67530 

35 

60342.86 

89.42 

99.907 

Initial 

em 

200 

20000 

mm 

67565 

3300 

59127.27 

87.51 

99.991 

Initial 

El 

200 

60000 

TM 

67565 

3300 

56327.27 

83.37 

99.973 

Initial 

El 

400 

5 

m 

87380 

35 

35869.71 

41.05 

99.987 

Initial 

El 

400 

194 

m 

87380 

35 

76546.86 

87.60 

99.987 

Initial 

El 

400 

500 

mm 

87550 

35 

77928.57 

89.02 

99.974 

Initial 

E 

400 

2000 

mm 

87660 

35 

78457.14 

89.50 

99.922 

Initial 

El 

400 

20000 

m 

87710 

3300 

77109.09 

87.91 

99.993 

Initial 

El 

400 

60000 

m 

87720 

3300 

74309.09 

84.72 

99.979 

Initial 

600 

5 

mm 

97130 

35 

39818.00 

41.00 

99.982 

Initial 

600 

194 

mm 

97130 

35 

84972.00 

87.49 

99.982 

Initial 

171 

600 

500 

m 

97130 

35 

86485.71 

89.04 

99.982 

Initial 

El 

600 

2000 

wm 

97330 

35 

86971.43 

89.37 

99.930 

Initial 

El 

600 

20000 

m 

97390 

3300 

85927.27 

88.23 

99.994 

Initial 

El 

600 

60000 

mm 

97400 

3300 

82963.64 

85.19 

99.981 

Initial 

El 

800 

5 

mm 

102860 

35 

42150.29 

40.98 

99.978 

Initial 

mm 

800 

194 

m 

102860 

35 

89949.49 

87.45 

99.978 

Initial 

mm 

800 

500 

mm 

102860 

35 

91557.14 

89.01 

99.978 

Initial 

El 

800 

2000 

m 

103020 

35 

92285.71 

89.62 

99.934 

Initial 

E 

800 

20000 

m 

103080 

3300 

90915.15 

88.20 

99.994 

Initial 

mm 

800 

60000 

m 

103090 

3300 

87890.91 

85.27 

99.982 

Initial 

mm 

1000 

5 

mm 

106640 

35 

43662.00 

40.95 

99.973 

Initial 

mm 

1000 

194 

mm 

106640 

35 

93175.43 

87.37 

99.973 

Initial 

El 

1000 

500 

m 

106640 

35 

94857.14 

88.96 

99.973 

Initial 

El 

1000 

2000 

mm 

106770 

35 

95542.86 

89.51 

99.920 

Initial 

El 

1000 

20000 

m. 

106830 

750 

94480.00 

88.44 

99.974 

Initial 

El 

1000 

60000 

mm 

106830 

750 

91840.00 

85.99 

99.924 
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Table  27.  Raw  Experimental  Results  in  Tabular  Form  (Part  3  of  5) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Fen 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

ATM 

Ri 

179 

173 

m 

115820 

35 

101573.76 

87.70 

99.995 

Second 

wm 

41 

50 

m 

94740 

35 

77553.43 

81.86 

99.998 

Second 

mm 

41 

100 

m 

95390 

35 

81828.57 

85.78 

99.996 

Second 

wm 

41 

150 

m 

95710 

35 

83322.00 

87.06 

99.995 

Second 

200 

50 

El 

116720 

35 

94334.00 

80.82 

99.995 

Second 

200 

100 

m 

116720 

35 

99589.14 

85.32 

99.995 

Second 

200 

150 

m. 

116720 

35 

101400.86 

86.88 

99.995 

Second 

El 

400 

50 

m 

120720 

35 

96791.72 

80.18 

99.991 

Second 

El 

400 

100 

m 

120720 

35 

102242.28 

84.69 

99.991 

Second 

400 

150 

m 

120720 

35 

104137.70 

86.26 

99.991 

Second 

600 

50 

m 

122110 

35 

97570.00 

79.90 

99.986 

Second 

600 

100 

n 

122110 

35 

103069.70 

84.41 

99.986 

Second 

600 

150 

m 

122110 

35 

104946.86 

85.95 

99.986 

Second 

H 

800 

50 

m 

122820 

35 

97761.43 

79.60 

99.981 

Second 

EB 

800 

100 

m 

122820 

35 

103251.42 

84.07 

99.981 

Second 

El 

800 

150 

n 

122820 

35 

105160.26 

85.62 

99.981 

Second 

El 

1000 

50 

o 

123250 

35 

97872.28 

79.41 

99.977 

Second 

Kil 

1000 

100 

m 

123250 

35 

103295.40 

83.81 

99.977 

Second 

mm 

1000 

150 

o 

123250 

35 

105297.40 

85.44 

99.977 

Second 

mm 

41 

50 

■a 

24165 

35 

19512.86 

80.75 

99.990 

Second 

41 

100 

E9 

24205 

35 

20608.57 

85.15 

99.986 

Second 

mm 

41 

150 

E9 

24226 

35 

21000.00 

86.69 

99.981 

Second 

mm 

200 

50 

m, 

67170 

35 

54275.71 

80.81 

99.992 

Second 

200 

100 

m 

67170 

35 

57340.00 

85.37 

99.992 

Second 

200 

150 

m 

67170 

35 

58435.71 

87.00 

99.992 

Second 

400 

50 

m 

87380 

35 

70455.71 

80.63 

99.987 

Second 

400 

100 

m 

87380 

35 

74434.29 

85.19 

99.987 

Second 

KTi!il 

400 

150 

■a 

87380 

35 

75865.71 

86.83 

99.987 

Second 

600 

50 

m 

97130 

35 

78208.57 

80.52 

99.982 

Second 

600 

100 

E9 

97130 

35 

82631.43 

85.07 

99.982 

Second 

600 

150 

■a 

97130 

35 

84214.29 

86.71 

99.982 

Second 

wm 

800 

50 

m 

102860 

35 

82791.43 

80.49 

99.978 

Second 

800 

100 

m 

102860 

35 

87471.43 

85.04 

99.978 

Second 

800 

150 

m 

102860 

35 

89147.14 

86.67 

99.978 

Second 

IBfl 

1000 

50 

m 

106640 

35 

85761.43 

80.42 

99.97.3 

Second 

108 

1000 

100 

■a 

106640 

35 

90608.57 

84.97 

99.973 

Second 

1B51 

1000 

150 

m 

106640 

35 

92344.29 

86.60 

99.973 
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Table  28.  Raw  Experimental  Results  in  Tabular  Form  (Part  4  of  5) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Fen 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

Third 

DQI 

41 

300 

m 

96200 

35 

84723.43 

88.07 

99.990 

Third 

US 

41 

1000 

la 

96540 

35 

85068.57 

88.14 

99.970 

Third 

41 

6000 

m 

96670 

35 

84000.00 

87.03 

99.822 

Third 

200 

300 

m 

117320 

35 

103138.26 

87.91 

99.990 

Third 

200 

1000 

m 

117720 

35 

103885.70 

88.25 

99.971 

Third 

200 

6000 

m 

117890 

35 

102617.14 

87.13 

99.850 

Third 

iSS 

400 

300 

■9 

120720 

35 

105963.44 

87.78 

99.991 

Third 

400 

1000 

19 

121140 

35 

106765.72 

88.15 

99.972  ' 

Third 

400 

6000 

m 

121320 

35 

105565.72 

87.10 

99.849  ! 

Third 

600 

300 

m 

122110 

35 

106880.56 

87.53 

99.986 

Third 

600 

1000 

■9 

122330 

35 

107708.58 

88.06 

99.972 

Third 

600 

6000 

■9 

122510 

35 

107005.70 

87.42 

99.846 

Third 

800 

300 

19 

122820 

35 

107117.16 

87.22 

99.981 

Third 

800 

1000 

■9 

122990 

35 

107994.28 

87.82 

99.963 

Third 

IB 

800 

6000 

■9 

123110 

35 

107108.60 

87.02 

99.852 

Third 

1000 

300 

m 

123250 

35 

107364.00 

87.11 

99.977 

Third 

1000 

1000 

m 

123390 

35 

108360.00 

87.83 

99.954 

Third 

KB 

1000 

6000 

K9 

123480 

35 

107519.98 

87.11 

99.838 

Third 

BEI 

41 

300 

D 

24258 

35 

21394.29 

88.20 

99.961 

Third 

41 

1000 

El 

24280 

35 

21628.57 

89.16 

99.879 

Third 

gig 

41 

6000 

El 

24287 

35 

21428.57 

88.65 

99.291 

Third 

200 

300 

El 

67370 

35 

59571.43 

88.43 

99.983 

Third 

200 

1000 

m 

67500 

35 

60314.29 

89.37 

99.949 

Third 

200 

6000 

El 

67555 

35 

59828.57 

88.58 

99.738  ■ 

Third 

ill 

400 

300 

m 

87380 

35 

77322.86 

88.49 

99.987 

Third 

400 

1000 

m 

87610 

35 

78342.86 

89.43 

99.961 

Third 

400 

6000 

n 

87700 

35 

78171.43 

89.24 

99.792 

Third 

600 

300 

El 

97130 

35 

85842.86 

88.39 

99.982 

Third 

600 

1000 

US 

97260 

35 

86942.86 

89.39 

99.965 

Third 

IES1 

600 

6000 

El 

97380 

35 

86742.86 

89.08 

99.806 
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Table  29.  Raw  Experimental  Results  in  Tabular  Form  (Part  5  of  5) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Fen 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

Third 

BEBI 

800 

300 

B 

102860 

35 

90874.29 

88.35 

99.978 

Third 

na 

800 

1000 

B9 

102980 

35 

92057.14 

89.40 

99.956 

Third 

BEB 

800 

6000 

m 

103060 

35 

91885.71 

89.18 

99.823 

Third 

BEB 

1000 

300 

m 

106640 

35 

94131.43 

88.27 

99.973  I 

Third 

1000 

1000 

m 

106740 

35 

95342.86 

89.34 

99.947 

Third 

B9 

1000 

6000 

m 

106810 

35 

95314.29 

89.25 

99.813 

Third 

Hgi 

41 

700 

m 

96480 

35 

85 1 64.00 

88.29 

99.978 

Third 

41 

1400 

m 

96380 

35 

84992.00 

88.02 

99.958 

Third 

200 

700 

m 

117620 

35 

103772.00 

88.24 

99.981 

Third 

200 

1400 

m 

117770 

35 

103704.00 

88.06 

99.961 

Third 

8E3 

400 

700 

m 

121040 

35 

106684.00 

88.14 

99.981 

Third 

BE7I 

400 

1400 

m 

121200 

35 

106672.00 

88.04 

99.962 

Third 

600 

700 

m 

122330 

35 

107672.00 

88.02 

99.972 

Third 

600 

1400 

m 

122400 

35 

107624.00 

87.96 

99.958 

Third 

800 

700 

m 

122820 

35 

107996.00 

87.94 

99.981 

Third 

800 

1400 

m 

122990 

35 

108144.00 

87.95 

99.963 

Third 

BBS 

1000 

700 

a 

123250 

35 

108188.00 

87.79 

99.977 

Third 

BB1 

1000 

1400 

o 

123390 

35 

108264.00 

87.76 

99.954 

Third 

BEB 

41 

700 

B 

24275 

35 

21600.00 

89.04 

99.913 

Third 

BEE1 

41 

1400 

m 

24283 

35 

21600.00 

88.96 

99.831 

Third 

200 

700 

B 

67470 

35 

60200.00 

89.24 

99.966 

Third 

200 

1400 

B 

67520 

35 

60360.00 

89.45 

99.932 

Third 

400 

700 

m 

87550 

35 

78140.00 

89.26 

99.974  1 

Third 

400 

1400 

m 

87635 

35 

78480.00 

89.59 

99.948 

Third 

600 

700 

m 

97260 

35 

86800.00 

89.25 

99.965 

Third 

600 

1400 

m 

97310 

35 

87040.00 

89.47 

99.947 

Third 

800 

700 

B 

102860 

35 

91860.00 

89.32 

99.978 

Third 

800 

1400 

m 

102980 

35 

92160.00 

89.51 

99.956  1 

Third 

1000 

700 

m 

106640 

35 

95160.00 

89.23 

99.973  ! 

Third 

BEB 

1000 

1400 

B 

106740 

35 

95480.00 

89.47 

99.947  | 

139 


Table  30.  Selected  Throughput  Results  Sorted  By  Source  Packet  Payload  Length 


NO  RS 


TF  Len  (bvtes)  ThrouahDut 


41  39514.29 


200  48070.49 


_ 4001  49283.17 


600  49698.43 


800  49809.97 


1000  49856.57 


SPLen  =  5  bytes 


tgiEtai  EjHjjjjjjjj3jjlj|j^j 


RS 


9936.00 


27633.14 


35869.71 


39818.00 


42150.29 


43662.00 


SP  Len  =  5  bytes 


ill 

ThrouahDut  (Bds 

SP  Len  =  194  bytes 

TF  Len  (bvtes 

n 

ThrouahDut  (Bds 

84006.43 


102609.38 


105274.38 


106076.98 


106272.08 


106389.60 


TF  Len  (bvtes) 

ThrouahDut  (Bds) 

41 

85194.28 

200 

103762.88 

400 

106471.42 

600 

107445.70 

800 

107751.42 

1000 

107951.42 

21179.26 


58970.46 


76546.86 


84972.00 


89949.49 


93175.43 


TF  Len  (bvtes)  I  Throughput  (Bps)  ISP  Len  =  500  bytes 


21528.57 


60000.00 


77928.57 


86485.71 


91557.14 


94857.14 


TF  Len  (bvtes)  I  Throughput  (Bps)  ISP  Len  =  1000  bytes 


85068.57 


103885.70 


106765.72 


107708.58 


107994.28 


108360.00 


TF  Len  (bvtes) 

ThrouahDut  (Bds) 

41 

84868.57 

200 

103588.56 

400 

106422.88 

600 

107542.88 

800 

107931.44 

1000 

108022.86 

TF  Len  (bvtes) 

ThrouahDut  (Bds) 

41 

21600.00 

200 

60360.00 

400 

78480.00 

600 

87040.00 

800 

92160.00 

1000 

95480.00 

TF  Len  (bvtes)  I  Throughput  (BdsI  ISP  Len  =  2000  bytes 


21542.86 


60342.86 


78457.14 


86971.43 


92285.71 


95542.86 


11 

ThrouahDut  (Bds 

Ll 

SP  Len  =  20000  bytes 

TF  Len  (bytes 

n 

ThrouahDut  (Bps 

82803.70 


101430.30 


104556.38 


105572.14 


105993.94 


106213.34 


78900.00 


97530.91 


100290.90 


101585.46 


101861.80 


102352.00 


20383.33 


59127.27 


77109.09 


85927.27 


90915.15 


94480.00 


11 

ThrouahDut  (Bps 

1 

SP  Len  =  60000  bytes 

TF  Len  (bytes 

i 

ThrouahDut  (Bps 

18411.11 


56327.27 


74309.09 


82963.64 


87890.91 


91840.00 


Table  31.  Selected  Throughput  Results  Sorted  By  Transfer  Frame  Length  (Part  1  of  2) 


)|  Throughput  (Bps 

si 

TF  Len  =  41  bytes  1 

SP  Len  (bytes) 

I  Throughput  (Bps 

39514.29 


77553.43 


81828.57 


83322.00 


84006.43 


85194.28 


85164.00 


85068.57 


84992.00 


84868.57 


82803.70 


78900.00 


TF  Len  =  41  bytes 


9936.00 


19512.86 


20608.57 


21000.00 


21179.26 


21528.57 


21600.00 


21628.57 


21600.00 


21542.86 


20383.33 


18411.11 


)|  Throughput  (Bps 

TF  Len  =  200  bytes  1 

SP  Len  (bytes) 

I  Throughput  (Bps 

48070.49 


94334.00 


99589.14 


101400.86 


102609.38 


103762.88 


103772.00 


103885.70 


103704.00 


103588.56 


101430.30 


97530.91 


SP  Len  (bytes) 

Threughput  (Bps) 

5 

49283.17 

50 

96791.72 

100 

102242.28 

150 

104137.70 

194 

105274.38 

500 

106471.42 

700 

106684.00 

1000 

106765.72 

1400 

106672.00 

2000 

106422.88 

20000 

104556.38 

60000 

100290.90 

27633.14 


54275.71 


57340.00 


58435.71 


58970.46 


60000.00 


60200.00 


60314.29 


60360.00 


60342.86 


59127.27 


56327.27 


SP  Len  (bvtes)l  Throughput  (Bps)  I  TF  Len  =  400  bytes 


35869.71 


70455.71 


74434.29 


75865.71 


76546.86 


77928.57 


78140.00 


78342.86 


78480.00 


78457.14 


77109.09 


74309.09 


Table  32.  Selected  Throughput  Results  Sorted  By  Transfer  Frame  Length  (Part  2  of  2) 


NO  RS _ RS 


SP  Len  (bvtes) 

Throughput  (Bps) 

TF  Len  =  600  bytes 

5 

49698.43 

50 

97570.00 

100 

103069.70 

150 

104946.86 

1  194 

106076.98 

500 

107445.70 

700 

107672.00 

1000 

107708.58 

1400 

107624.00 

2000 

107542.88 

20000 

105572.14 

1  60000 

101585.46 

SP  Len  (bvtes) 

Throughput  (Bps) 

TFLen  =  600  bytes 

5 

39818.00 

50 

78208.57 

100 

82631.43 

150 

84214.29 

194 

84972.00 

500 

86485.71 

700 

86800.00 

1000 

86942.86 

1400 

87040.00 

2000 

86971.43 

20000 

85927.27 

60000 

82963.64 

SP  Len  (bvtes) 

Throughput  (Bps) 

TF  Len  =  800  bytes 

5 

49809.97 

50 

97761.43 

100 

103251.42 

!  150 

105160.26 

194 

106272.08 

500 

107751.42 

700 

107996.00 

I  1000 

107994.28 

1400 

108144.00 

2000 

107931.44 

20000 

105993.94 

60000 

101861.80 

SP  Len  (bvtes) 

Throughput  (Bps) 

TF  Len  =  800  bytes 

5 

42150.29 

50 

82791.43 

100 

87471.43 

150 

89147.14 

194 

89949.49 

500 

91557.14 

700 

91860.00 

1000 

92057.14 

1400 

92160.00 

2000 

92285.71 

20000 

90915.15 

60000 

87890.91 

SP  Len  (bvtes) 

Throughput  (Bps) 

TF  Len  =  1000  bytes 

5 

49856.57 

|  50 

97872.28 

100 

103295.40 

150 

105297.40 

!  194 

106389.60 

500 

107951.42 

700 

108188.00 

1000 

108360.00 

1400 

108264.00 

2000 

108022.86 

!  20000 

106213.34 

1  60000 

102352.00 

SP  Len  (bvtes) 

Throughput  (Bps) 

TFLen  =  1000  bytes 

5 

43662.00 

50 

85761.43 

100 

90608.57 

150 

92344.29 

194 

93175.43 

500 

94857.14 

700 

95160.00 

1000 

95342.86 

1400 

95480.00 

2000 

95542.86 

20000 

94480.00 

60000 

91840.00 
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Throughput  (bytes  per  second  Throughput  (bytes  per  second 


119000 


0  200  400  600  800  1000  1200 


Source  Packet 
Payload  Length 

♦  5  bytes  (No  RS) 

H  194  bytes  (No  RS) 

•  500  bytes  (No  RS) 
2000  bytes  (No  RS) 

X 20000  bytes  (No  RS) 
•60000  bytes  (No  RS) 
-t- 5  bytes  (RS) 

-194  bytes  (RS) 

500  bytes  (RS) 
O2000  bytes  (RS) 
20000  bytes  (RS) 

A 60000  bytes  (RS) 


Transfer  Frame  Payload  Length  (bytes) 


Figure  44.  Throughput  Variation  With  Transfer  Frame  Length  In  Graphical  Format 


Source  Packet 
Payload  Length 

♦  5  bytes  (No  RS) 

■  1 94  bytes  (No  RS) 
±500  bytes  (No  RS) 

2000  bytes  (No  RS) 
X  20000  bytes  (No  RS) 

•  60000  bytes  (No  RS) 
+5  bytes  (RS) 

■  1 94  bytes  (RS) 

500  bytes  (RS) 

O2000  bytes  (RS) 
20000  bytes  (RS) 

A 60000  bytes  (RS) 


Transfer  Frame  Payload  Length  (bytes) 


Figure  45.  Throughput  Variation  With  Source  Packet  Length  In  Graphical  Format 
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Table  33.  Selected  Data  Quality  Results  Sorted  By  Source  Packet  Length 


NO  RS 

RS 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  5  bytes 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  5  bytes 

41 

42.55 

41 

41.33 

200 

41.19 

200 

41.14 

400 

40.83 

400 

41.05 

600 

40.70 

600 

41.00 

800 

40.56 

800 

40.98 

1000 

40.45 

1000 

40.95 

TF  Len  (bytes)  Data  Quality  (%)  SP  Len  =  1 94  bytes 


F  Len  (bytes)  Data  Quality  (%)  SP  Len  =  194  bytes 


TF  Len  (bytes)  Data  Quality  (%)  SP  Len  =  500  bytes 


F  Len  (bytes)  Data  Quality  (%)  SP  Len  =  500  bytes 


TF  Len  (bytes)  Data  Quality  (%)  SP  Len  =  1 000  bytes 


F  Len  (bytes)  Data  Quality  (%)  SP  Len  =  1400  bytes 


TF  Len  (bytes)  Data  Quality  (%)  SP  Len  =  2000  bytes 


F  Len  (bytes)  Data  Quality  (%)  SP  Len  =  2000  bytes 


TF  Len  (bytes)  Data  Quality  (%)  SP  Len  =  20000  bytes 


F  Len  (bytes)  Data  Quality  (%)  SP  Len  =  20000  bytes 


TF  Len  (bytes)  Data  Quality  (%)  SP  Len  =  60000  bytes 
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Table  34.  Selected  Data  Quality  Results  Sorted  By  Transfer  Frame  Length  (Part  1  of  2) 


No  RS _ RS 


SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  41  bytes 

5 

42.55 

50 

81.86 

100 

85.78 

150 

87.06 

194 

87.59 

300 

88.07 

500 

88.39 

700 

88.29 

1000 

88.14 

1400 

88.02 

2000 

87.88 

6000 

87.03 

20000 

85.64 

60000 

81.60 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  41  bytes 

5 

41.33 

50 

80.75 

100 

85.15 

150 

86.69 

194 

87.38 

300 

88.20 

500 

88.75 

700 

89.04 

1000 

89.16 

1400 

88.96 

2000 

88.92 

6000 

88.65 

20000 

83.93 

75.82 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  200  bytes 

5 

41.19 

50 

80.82 

100 

85.32 

150 

86.88 

194 

87.91 

300 

87.91 

500 

88.30 

700 

88.24 

1000 

88.25 

1400 

88.06 

2000 

87.96 

6000 

87.13 

20000 

86.02 

60000 

82.72 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  200  bytes 

5 

41.14 

50 

80.81 

100 

85.37 

150 

87.00 

194 

87.80 

300 

88.43 

500 

88.98 

700 

89.24 

1000 

89.37 

1400 

89.45 

2000 

89.42 

6000 

88.58 

20000 

87.51 

60000 

83.37 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  400  bytes 

5 

40.83 

50 

80.18 

100 

84.69 

150 

86.26 

194 

87.21 

300 

87.78 

500 

87.97 

700 

88.14 

1000 

88.15 

1400 

88.04 

2000 

87.81 

6000 

87.10 

20000 

86.16 

60000 

82.65 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  400  bytes 

5 

41.05 

50 

80.63 

100 

85.19 

150 

86.83 

194 

87.60 

300 

88.49 

500 

89.02 

700 

89.26 

1000 

89.43 

1400 

89.59 

2000 

89.50 

6000 

89.24 

20000 

87.91 

60000 

84.72  1 
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Table  35.  Selected  Data  Quality  Results  Sorted  By  Transfer  Frame  Length  (Part  2  of  2) 


No  RS _ RS 


SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  600  bytes 

5 

40.70 

50 

79.90 

100 

84.41 

150 

85.95 

194 

86.87 

300 

87.53 

500 

88.00 

700 

88.02 

1000 

88.06 

1400 

87.96 

2000 

87.86 

6000 

87.42 

20000 

86.15 

82.91 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  600  bytes 

5 

41.00 

50 

80.52 

100 

85.07 

150 

86.71 

194 

87.49 

300 

88.39 

500 

89.04 

700 

89.25 

1000 

89.39 

1400 

89.47 

2000 

89.37 

6000 

89.08 

20000 

88.23 

85.19 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  800  bytes 

5 

40.56 

50 

79.60 

100 

84.07 

150 

85.62 

194 

86.53 

300 

87.22 

500 

87.74 

700 

87.94 

1000 

87.82 

1400 

87.95 

2000 

87.73 

6000 

87.02 

20000 

86.08 

82.72 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  800  bytes 

5 

40.98 

50 

80.49 

100 

85.04 

150 

86.67 

194 

87.45 

300 

88.35 

500 

89.01 

700 

89.32 

1000 

89.40 

1400 

89.51 

2000 

89.62 

6000 

89.18 

20000 

88.20 

85.27 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  1 000  bytes 

5 

40.45 

50 

79.41 

100 

83.81 

150 

85.44 

194 

86.32 

300 

87.11 

500 

87.59 

700 

87.79 

1000 

87.83 

1400 

87.76 

2000 

87.52 

6000 

87.11 

20000 

86.01 

60000 

82.92 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  1000  bytes 

5 

40.95 

50 

80.42 

100 

84.97 

150 

86.60 

194 

87.37 

300 

88.27 

500 

88.96 

700 

89.23 

1000 

89.34 

1400 

89.47 

2000 

89.51 

6000 

89.25 

20000 

88.44 

60000 

85.99 
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Data  Quality  (%]  Data  Quality  (%] 


Source  Packet 
Payload  Length 


♦  5  bytes  (No  RS) 

■  194  bytes  (No  RS) 
500  bytes  (No  RS) 
2000  bytes  (No  RS) 
X  20000  bytes  (No  RS) 

•  60000  bytes  (No  RS) 
+  5  bytes  (RS) 

-  194  bytes  (RS) 

500  bytes  (RS) 

2000  bytes  (RS) 
20000  bytes  (RS) 

A  60000  bytes  (RS) 


Transfer  Frame  Payload  Length  (bytes) 


Figure  46.  Data  Quality  Variation  With  Transfer  Frame  Length  In  Graphical  Format 


Transfer  Frame 
Payload  Length 

♦  41  bytes  (No  RS) 

■  200  bytes  (No  RS) 

400  bytes  (No  RS) 
600  bytes  (No  RS) 
X  800  bytes  (No  RS) 

•  1000  bytes  (No  RS) 
+  41  bytes  (RS) 

-  200  bytes  (RS) 

400  bytes  (RS) 

600  bytes  (RS) 

800  bytes  (RS) 

A  1000  bytes  (RS) 


Source  Packet  Payload  Length  -  Log  Scale  (bytes) 


Figure  47.  Data  Quality  Variation  With  Source  Packet  Length  In  Graphical  Format 
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APPENDIX  H  -  Raw  Flight  Test  Data 


This  appendix  lists  the  throughput,  data  quality,  and  channel  utilization  results 
from  each  flight  test  data  run.  Sample  size  varied  given  flight  test  conditions  and  time 
constraints.  A  representative  confidence  level  was  80%,  with  throughput  data  accurate  to 
within  ±935  Bps  and  data  quality  accurate  to  within  ±0.92  percentage  points.  Confidence 
and  accuracy  calculations  are  shown  in  Appendix  E.  The  following  tables  and  figures  are 
provided  in  this  appendix: 


Table  36. 
Table  37. 
Table  38. 
Table  39. 
Figure  48. 
Figure  49. 
Table  40. 
Table  41. 
Figure  50. 
Figure  5 1 . 


Raw  Flight  Test  Results  in  Tabular  Form  (Part  1  of  2) 

Raw  Flight  Test  Results  in  Tabular  Form  (Part  2  of  2) 

Flight  Test  Throughput  Results  Sorted  By  Source  Packet  Fength 
Flight  Test  Throughput  Results  Sorted  By  Transfer  Frame  Fength 
Flight  Test  Variation  in  Throughput  With  Transfer  Frame  Fength 
Flight  Test  Variation  in  Throughput  With  Source  Packet  Fength 
Flight  Test  Data  Quality  Results  Sorted  By  Source  Packet  Fength 
Flight  Test  Data  Quality  Results  Sorted  By  Transfer  Frame  Fength 
Flight  Test  Data  Quality  Variation  With  Transfer  Frame  Fength 
Flight  Test  Data  Quality  Variation  With  Source  Packet  Fength 
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Table  36.  Raw  Flight  Test  Results  in  Tabular  Form  (Part  1  of  2) 


Type 

R 

u 

n 

TF  Len 

(bytes) 

SP  Len 

(bytes) 

RS 

Run 

Length 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Initial 

1 

50 

30 

El 

743 

73047.62 

90.81 

Initial 

mm 

50 

194 

m 

711 

91286.96 

97.49 

Initial 

50 

500 

m 

725 

88852.41 

96.43 

Initial 

■n 

50 

2000 

m 

697 

88370.16 

93.02 

Initial 

K3 

50 

20000 

m 

720 

82694.44 

88.71 

Initial 

L_6_J 

50 

60000 

m 

717 

77991.63 

77.54 

Initial 

mm 

200 

30 

m 

707 

78790.69 

97.39 

Initial 

8 

200 

194 

m 

705 

107250.35 

96.59 

Initial 

9 

200 

500 

m 

742 

108934.64 

95.54 

Initial 

BBS 

200 

2000 

m 

719 

108350.49 

95.37 

Initial 

m 

200 

20000 

m 

725 

102206.90 

90.26 

Initial 

n 

200 

60000 

m 

723 

96265.56 

86.96 

Initial 

so 

400 

30 

m 

718 

91869.07 

92.95 

Initial 

KS 

400 

194 

m 

715 

113064.56 

97.43 

Initial 

BO 

400 

500 

m 

735 

102923.13 

90.43 

Initial 

BO 

400 

2000 

m 

726 

112662.87 

95.08 

Initial 

MSB 

400 

20000 

m 

731 

106183.31 

90.26 

Initial 

BO 

400 

60000 

m 

707 

101669.02 

88.35 

Initial 

BO 

600 

30 

m 

711 

97950.46 

96.89 

Initial 

BBS 

600 

194 

m 

715 

113958.86 

97.14 

Initial 

mm 

600 

500 

ri 

716 

112728.35 

96.54 

Initial 

600 

2000 

IBS 

745 

111524.83 

93.16 

Initial 

600 

20000 

m 

726 

97465.56 

82.59 

Initial 

MUM 

600 

60000 

m 

720 

100166.67 

85.86 

Initial 

BO 

800 

30 

m 

710 

93640.52 

92.16 

Initial 

800 

194 

m 

729 

115357.08 

97.73 

Initial 

800 

500 

m 

720 

116551.39 

97.29 

Initial 

BO 

800 

2000 

m 

747 

114000.00 

90.13 

Initial 

800 

20000 

m 

716 

111759.78 

93.22 

Initial 

BO 

800 

60000 

o 

718 

104958.22 

89.52 
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Table  37.  Raw  Flight  Test  Results  in  Tabular  Form  (Part  2  of  2) 


Type 

R 

u 

n 

TF  Len 

(bytes) 

SP  Len 

(bytes) 

RS 

Run 

Length 

(sec) 

Throughput 

(Bps) 

■HI 

Initial 

eh 

1000 

30 

MM 

723 

93083.11 

91.34 

Initial 

1000 

194 

El 

745 

113640.25 

95.97 

Initial 

EH 

1000 

500 

m 

700 

107037.14 

89.77 

Initial 

1000 

2000 

m 

732 

114188.52 

94.20 

Initial 

1000 

20000 

m 

719 

103282.34 

86.67 

Initial 

1000 

60000 

ra 

729 

91934.16 

79.11 

Initial 

939 

30 

D 

709 

83809.21 

95.87 

Initial 

939 

194 

D 

713 

95107.34 

93.68 

Initial 

939 

500 

m 

719 

90050.76 

87.60 

Initial 

Elil 

939 

2000 

a 

728 

98320.66 

95.01 

Initial 

EH 

939 

20000 

D 

710 

84028.17 

83.67 

Initial 

EE 1 

939 

60000 

El 

736 

78505.43 

79.39  1 

Second 

mm 

125 

30 

El 

716 

data  invalid 

data  invalid 

Second 

EEl 

125 

194 

m 

730 

104944.17 

97.26 

Second 

125 

500 

m 

731 

103759.92 

94.69  1 

Second 

E!51 

125 

2000 

m 

725 

104733.79 

96.10 

Second 

mm 

125 

20000 

m 

703 

data  invalid 

data  invalid 

Second 

125 

60000 

m 

712 

data  invalid 

data  invalid 

ATM 

198 

192 

m 

724 

107898.93 

96.88 

Second 

ETil 

300 

100 

m 

727 

102504.54 

91.85 

Second 

ET1 

300 

350 

m 

725 

103305.03 

89.59 

Second 

ra 

300 

750 

m 

712 

110534.41 

94.56 

Second 

EH 

300 

1000 

m 

728 

111145.60 

94.92 

Second 

d 

300 

5000 

m 

731 

109746.92 

93.95 

Second 

300 

40000 

El 

714 

100112.04 

87.77 

Second 

d 

500 

100 

N 

708 

97677.82 

96.40 

Second 

ra 

500 

350 

m 

730 

112508.70 

95.19 

Second 

EH 

500 

750 

ra 

725 

115038.62 

96.55 

Second 

d 

500 

1000 

m 

721 

114603.33 

96.18 

Second 

15B1 

500 

5000 

ra 

709 

107912.55 

90.81 

Second 

HI 

500 

40000 

El 

731 

103036.94 

88.11 
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Table  38.  Flight  Test  Throughput  Results  Sorted  By  Source  Packet  Length 


NO  RS 


TF  Len  (bytes) 

SPLen  =  30  bytes 

50 

73047.62 

200 

78790.69 

400 

91869.07 

600 

97950.46 

i  800 

93640.52 

1000 

93083.11 

RS 


I  939  | 

I  83809.21  | 

SP  Len  =  30  bytes 


TF  Len  (bytes) 

Throughput  (Bps) 

50 

91286.96 

125 

104944.17 

200 

107250.35 

400 

113064.56 

600 

113958.86 

800 

115357.08 

1000 

113640.25 

SP  Len  =  1 94  bytes 


TF  Len  (bytes) 

Throughput  (Bps) 

939 

95107.34 

SP  Len  =  1 94  bytes 


TF  Len  (bvtes) 

Throughout  (Bds) 

50 

88852.41 

125 

103759.92 

200 

108934.64 

400 

102923.13 

1  600 

112728.35 

800 

116551.39 

1000 

107037.14 

SP  Len  =  500  bytes 


TF  Len  (bvtesl 

Throughout  (BdsI 

939 

90050.76 

SP  Len  =  500  bytes 


TF  Len  (bytes) 

Throughput  (Bps) 

50 

88370.16 

125 

104733.79 

200 

108350.49 

400 

112662.87 

600 

111524.83 

800 

114000.00 

I  1000 

114188.52 

SP  Len  =  2000  bytes 


TF  Len  (bytes) 

Throughput  (Bps) 

939 

98320.66 

SP  Len  =  2000  bytes 


TF  Len  (bytes) 

Throughput  (Bps) 

SP  Len  =  20000  bytes 

50 

82694.44 

200 

102206.90 

400 

106183.31 

600 

97465.56 

800 

111759.78 

1000 

103282.34 

TF  Len  (bytes)  Throughput  (Bps)  SP  Len  =  20000  bytes 
939 _ 84028.17 _ 


TF  Len  (bvtesl 

Throughout  (Bds) 

SP  Len  =  60000  bytes 

50 

77991 .63 

200 

96265.56 

400 

101669.02 

!  600 

100166.67 

800 

104958.22 

1000 

91934.16 

TF  Len  (bytes)  Throughput  (Bps)  SP  Len  =  60000  bytes 
939 _ 78505.43 _ 
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Table  39.  Flight  Test  Throughput  Results  Sorted  By  Transfer  Frame  Length 


No  RS 


SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  50  bytes 

30 

73047.62 

194 

91286.96 

500 

88852.41 

2000 

88370.16 

20000 

82694.44 

60000 

77991.63 

RS 


SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  939  bytes 

30 

83809.21 

194 

95107.34 

500 

90050.76 

2000 

98320.66 

20000 

84028.17 

60000 

78505.43 

SP  Len  (bvtes) 

Throuqhput  (Bos) 

TF  Len  =  200  bytes 

30 

78790.69 

194 

107250.35 

500 

108934.64 

2000 

108350.49 

20000 

102206.90 

60000 

96265.56 

SP  Len  (bvtes) 

Throuqhput  (Bos) 

TF  Len  =  400  bytes 

30 

91869.07 

194 

113064.56 

500 

102923.13 

2000 

112662.87 

20000 

106183.31 

60000 

101669.02 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  600  bytes 

30 

97950.46 

194 

113958.86 

500 

112728.35 

2000 

111524.83 

20000 

97465.56 

60000 

100166.67 

SP  Len  (bvtes) 

Throuqhput  (Bos) 

TF  Len  =  800  bytes 

30 

93640.52 

194 

115357.08 

500 

116551.39 

2000 

114000.00 

20000 

111759.78 

60000 

104958.22 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  1000  bytes 

30 

93083.11 

194 

113640.25 

500 

107037.14 

2000 

114188.52 

20000 

103282.34 

60000 

91934.16 
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Figure  48.  Flight  Test  Variation  in  Throughput  With  Transfer  Frame  Length 
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Figure  49.  Flight  Test  Variation  in  Throughput  With  Source  Packet  Length 
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Table  40.  Flight  Test  Data  Quality  Results  Sorted  By  Source  Packet  Length 


NO  RS 


TF  Len  fbvtesl  I  Data  Quality  (% 


50 

90.81 

200 

97.39 

SP  Len  =  30  bytes 


600 

96.89 

800 

92.16 

TF  Len  Ibvtesl 

Data  Quality  t%1 

50 

97.49 

125 

97.26 

200 

96.59 

400 

97.43 

600 

97.14 

800 

97.73 

1000 

95.97 

TF  Len  Ibvtesl  I  Data  Quality  (%)  I  SP  Len  =  500  bytes 


TF  Len  tbvtesl 

Data  Quality  1%) 

50 

93.02 

125 

96.10 

200 

95.37 

400 

95.08 

SP  Len  =  2000  bytes 


TF  Len  fbvtesTI  Data  Quality  (%)  I  SP  Len  =  20000  bytes 


TF  Len  (bvtesl 

Data  Quality  (% ) 

50 

77.54 

200 

86.96 

400 

88.35 

600 

85.86 

800 

89.52 

1000 

79.11 

SP  Len  =  60000  bytes 
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Table  41.  Flight  Test  Data  Quality  Results  Sorted  By  Transfer  Frame  Length 


No  RS _ RS 


SP  Len  (bvtes) 

Data  Quality  (%) 

TF  Len  =  50  bytes 

30 

90.81 

194 

97.49 

500 

96.43 

2000 

93.02 

20000 

88.71 

60000 

77.54 

SP  Len  (bvtes) 

Data  Quality  (%) 

TF  Len  =  939  bytes 

30 

95.87 

194 

93.68 

500 

87.60 

2000 

95.01 

20000 

83.67 

60000 

79.39 

SP  Len  (bvtes) 

Data  Quality  (%) 

TF  Len  =  200  bytes 

30 

97.39 

194 

96.59 

500 

95.54 

2000 

95.37 

20000 

90.26 

60000 

86.96 

SP  Len  (bvtes) 

Data  Quality  (%) 

TF  Len  =  400  bytes 

30 

92.95 

194 

97.43 

500 

90.43 

2000 

95.08 

20000 

90.26 

60000 

88.35 

SP  Len  (bvtes) 

Data  Quality  (%) 

TF  Len  =  600  bytes 

30 

96.89 

194 

97.14 

500 

96.54 

2000 

93.16 

20000 

82.59 

60000 

85.86 

SP  Len  (bvtes) 

Data  Quality  (%) 

TF  Len  =  800  bytes 

30 

92.16 

194 

97.73 

500 

97.29 

2000 

90.13 

20000 

93.22 

60000 

89.52 

SP  Len  (bvtes) 

Data  Quality  (%) 

TF  Len  =  1 000  bytes 

30 

91.34 

194 

95.97 

500 

89.77 

2000 

94.20 

20000 

86.67 

60000 

79.11 
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Figure  50.  Flight  Test  Data  Quality  Variation  With  Transfer  Frame  Length 
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APPENDIX  1  -  Raw  Simulation  Data  (95-4-1  Channel  Model ) 


This  appendix  lists  the  throughput,  data  quality,  and  channel  utilization  results 
from  each  simulation  run  using  the  95-4-1  channel  model.  Values  shown  are  the 
arithmetic  mean  of  data  from  five  samples.  This  sample  size  yielded  a  worst-case 
confidence  of  90%.  Throughput  data  is  accurate  to  within  ±127  Bps.  Data  quality  data  is 
accurate  to  within  ±0.103  percentage  points.  Confidence  and  accuracy  calculations  are 
shown  in  Appendix  E.  The  following  tables  are  provided  in  this  appendix: 

Table  42.  Raw  Experimental  Results  in  Tabular  Form  (Part  1  of  3) 

Table  43.  Raw  Experimental  Results  in  Tabular  Form  (Part  2  of  3) 

Table  44.  Raw  Experimental  Results  in  Tabular  Form  (Part  3  of  3) 

Table  45.  Throughput  Results  Sorted  By  Source  Packet  Payload  Length 

Table  46.  Throughput  Results  Sorted  By  Transfer  Frame  Length 

Table  47.  Data  Quality  Results  Sorted  By  Source  Packet  Length 

Table  48.  Data  Quality  Results  Sorted  By  Transfer  Frame  Length  (Part  1  of  2) 

Table  49.  Data  Quality  Results  Sorted  By  Transfer  Frame  Length  (Part  2  of  2) 
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Table  42.  Raw  Experimental  Results  in  Tabular  Form  (Part  1  of  3) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Len 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

Initial 

i 

41 

5 

m 

92865 

80 

40531.69 

45.23 

99.999 

Initial 

mm 

41 

194 

■31 

95910 

80 

84816.80 

91.75 

99.997 

Initial 

mm 

41 

500 

■a 

96390 

80 

85131.25 

91.64 

99.993 

Initial 

H 

41 

2000 

m 

96620 

80 

87675.00 

91.33 

99.974 

Initial 

5 

41 

20000 

mg 

96690 

3000 

86126.67 

89.72 

99.993 

Initial 

6 

41 

60000 

m 

96700 

10800 

85876.67 

88.81 

99.994 

Initial 

7 

200 

5 

m 

116720 

80 

50611.63 

43.77 

99.998 

Initial 

wm 

200 

194 

m 

116720 

80 

108028.90 

93.42 

99.998 

Initial 

9 

200 

500 

wm 

117520 

80 

109643.80 

94.18 

99.994 

Initial 

wm 

200 

2000 

■a 

117810 

80 

109675.00 

93.98 

99.977 

Initial 

m 

200 

20000 

m 

117910 

755 

108264.90 

92.70 

99.977 

Initial 

mm 

200 

60000 

m 

117920 

3000 

104420.00 

89.39 

99.983 

Initial 

mm 

400 

5 

m 

120720 

80 

52225.88 

43.47 

99.996 

Initial 

SB 

400 

194 

wm 

120720 

80 

111457.90 

92.77 

99.996 

Initial 

mm 

400 

500 

■a 

121040 

80 

1 1  3456.30 

94.19 

99.992 

Initial 

mm 

400 

2000 

■a 

121250 

80 

113825.00 

94.34 

99.975 

Initial 

mm 

400 

20000 

it  3 

121350 

80 

111750.00 

92.55 

99.790 

Initial 

mm 

400 

60000 

m 

121350 

755 

109668.90 

90.85 

99.934 

Initial 

mm 

600 

5 

■a 

122110 

80 

52775.06 

43.36 

99.994 

Initial 

SHU 

600 

194 

m 

122110 

80 

112631.60 

92.53 

99.994 

Initial 

m 

600 

500 

is 

122110 

80 

114643.80 

94.19 

99.994 

Initial 

600 

2000 

H 

122440 

80 

115225.00 

94.43 

99.976 

Initial 

600 

20000 

■a 

122540 

80 

113000.00 

92.62 

99.792 

Initial 

siii 

600 

60000 

ra 

122540 

755 

110304.60 

90.36 

99.935 

Initial 

ra 

800 

5 

m 

122820 

80 

53058.13 

43.31 

99.992 

Initial 

800 

194 

m 

122820 

80 

113237.80 

92.43 

99.992 

Initial 

800 

500 

■a 

122820 

80 

1 15318.80 

94.12 

99.992 

Initial 

800 

2000 

■a 

123040 

80 

11 5975.00 

94.50 

99.976 

Initial 

800 

20000 

■a 

123140 

80 

113750.00 

92.67 

99.789 

Initial 

El 

800 

60000 

■a 

123150 

755 

111178.80 

90.55 

99.935 

Initial 

ETI 

1000 

5 

■a 

123250 

80 

53220.63 

43.27 

99.990 

Initial 

1000 

194 

■a 

123250 

80 

113574.90 

92.33 

99.990 

Initial 

1000 

500 

■a 

123250 

80 

115593.80 

93.97 

99.990 

Initial 

1000 

2000 

■a 

123430 

80 

116425.00 

94.52 

99.970 

Initial 

1000 

20000 

wm 

123500 

80 

113750.00 

92.29 

99.787 

Initial 

El 

1000 

60000 

m 

123510 

755 

111576.20 

90.52 

99.935 
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Table  43.  Raw  Experimental  Results  in  Tabular  Form  (Part  2  of  3) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Fen 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

Initial 

41 

5 

WM 

24040 

80 

10497.56 

44.08 

99.998 

Initial 

41 

194 

m 

24240 

80 

22385.17 

93.23 

99.989 

Initial 

41 

500 

m 

24270 

80 

22787.50 

94.80 

99.973 

Initial 

Eil 

41 

2000 

wm 

24285 

80 

22750.00 

94.59 

99.897 

Initial 

wm 

41 

20000 

m 

24288 

3000 

21646.67 

89.99 

99.973 

Initial 

ESI 

41 

60000 

m 

24288 

10800 

19661.11 

81.73 

99.977 

Initial 

ia 

200 

5 

m 

67170 

80 

29316.75 

43.88 

99.996 

Initial 

El 

200 

194 

E9 

67170 

80 

62562.57 

93.64 

99.996 

Initial 

El 

200 

500 

WM 

67432 

80 

63693.75 

94.97 

99.989 

Initial 

Wti 1 

200 

2000 

wm 

67530 

80 

64000.00 

95.31 

99.959 

Initial 

wm 

200 

20000 

m 

67565 

755 

63046.36 

93.85 

99.960 

Initial 

200 

60000 

m 

67565 

3000 

60300.00 

89.73 

99.970 

Initial 

400 

5 

wm 

87380 

80 

38129.13 

43.79 

99.994 

Initial 

Eil 

400 

194 

m 

87380 

80 

81368.45 

93.44 

99.994 

Initial 

El 

400 

500 

wm 

87550 

80 

82850.00 

94.96 

99.989 

Initial 

151 

400 

2000 

n 

87660 

80 

83350.00 

95.42 

99.966 

Initial 

El 

400 

20000 

wm 

87710 

80 

82000.00 

93.98 

99.709 

Initial 

El 

400 

60000 

wm 

87720 

755 

80105.96 

91.72 

99.909 

Initial 

El 

600 

5 

m 

97130 

80 

42371.25 

43.74 

99.992 

Initial 

600 

194 

tm 

97130 

80 

90420.98 

93.33 

99.992 

Initial 

El 

600 

500 

m 

97130 

80 

92075.00 

95.05 

99.992 

Initial 

El 

600 

2000 

wm 

97330 

80 

92700.00 

95.54 

99.969 

Initial 

El 

600 

20000 

wm 

97390 

80 

91250.00 

94.07 

99.738 

Initial 

El 

600 

60000 

mm 

97400 

755 

89086.09 

91.73 

99.918 

Initial 

mm 

800 

5 

m 

102860 

80 

44863.38 

43.71 

99.990 

Initial 

mm 

800 

194 

m 

102860 

80 

95739.00 

93.27 

99.990 

Initial 

HI 

800 

500 

wm 

102860 

80 

97481.25 

94.96 

99.990 

Initial 

m 

800 

2000 

m 

103020 

80 

98250.00 

95.57 

99.971 

Initial 

mm, 

800 

20000 

m 

103080 

80 

96500.00 

93.92 

99.748 

Initial 

wm 

800 

60000 

WM 

103090 

755 

95682.12 

93.04 

99.922 

Initial 

wm 

1000 

5 

WM 

106640 

80 

46494.06 

43.68 

99.988 

Initial 

1000 

194 

■a 

106640 

80 

99218.88 

93.20 

99.988 

Initial 

El 

1000 

500 

wm 

106640 

80 

101025.00 

94.90 

99.988 

Initial 

El 

1000 

2000 

WM 

106770 

80 

101800.00 

95.52 

99.965 

Initial 

wa 

1000 

20000 

WM 

106830 

80 

1 00500.00 

94.37 

99.754 

Initial 

El 

1000 

60000 

m 

106830 

755 

98781.46 

92.62 

99.924 
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Table  44.  Raw  Experimental  Results  in  Tabular  Form  (Part  3  of  3) 


Type 

R 

u 

n 

TF  Fen 

(bytes) 

SP  Fen 

(bytes) 

RS 

SP  Data 

Rate 

(Bps) 

Sim 

Fength 

(sec) 

Throughput 

(Bps) 

SP  Data 
Quality 

(%) 

Channel 

Utilization 

(%) 

ATM 

B 51 

179 

173 

m 

115820 

80 

107884.80 

93.37 

98.865 

Second 

mm 

41 

1000 

n 

96540 

80 

85050.00 

91.43 

99.987 

Second 

Cl 

200 

1000 

m 

117720 

80 

109612.50 

94.00 

99.987  1 

Second 

WM 

400 

1000 

o 

121140 

80 

113900.00 

94.48 

99.988 

Second 

600 

1000 

o 

122330 

80 

115162.50 

94.45 

99.988  I 

Second 

800 

1000 

m 

122990 

80 

115862.50 

94.45 

99.984 

Second 

1000 

1000 

m 

123390 

80 

116237.50 

94.40 

99.980  I 

Second 

El 

41 

1000 

m 

24280 

80 

22800.00 

94.80 

99.947 

Second 

ma 

200 

1000 

m 

67500 

80 

64000.00 

95.33 

99.978 

Second 

SH 

400 

1000 

K9 

87610 

80 

83312.50 

95.43 

99.983 

Second 

ra 

600 

1000 

m 

97260 

80 

92575.00 

95.44 

99.985 

Second 

m 

800 

1000 

m 

102980 

80 

98050.00 

95.43 

99.981  t 

Second 

mm 

1000 

1000 

m 

106740 

80 

101587.50 

95.34 

99.977 

Second 

ra 

41 

6000 

o 

96670 

80 

86925.00 

90.62 

99.922 

Second 

El 

200 

6000 

m 

117890 

80 

108975.00 

93.32 

99.934 

Second 

BSE1 

400 

6000 

m 

121320 

80 

113325.00 

93.91 

99.934 

Second 

El 

600 

6000 

m 

122510 

80 

114825.00 

94.04 

99.933 

Second 

m§ 

800 

6000 

m 

123110 

80 

115425.00 

94.01 

99.935 

Second 

mm 

1000 

6000 

m 

123480 

80 

115875.00 

94.04 

99.929 

Second 

m 

41 

6000 

WM 

24287 

80 

22425.00 

93.44 

99.690 

Second 

wm 

200 

6000 

m 

67555 

80 

63750.00 

94.97 

99.885 

Second 

mm 

400 

6000 

■9 

87700 

80 

83100.00 

95.11 

99.909 

Second 

mm 

600 

6000 

E9 

97380 

80 

92475.00 

95.21 

99.915  ! 

Second 

mm 

800 

6000 

m 

103060 

80 

98100.00 

95.40 

99.922 

Second 

mm 

1000 

6000 

m 

106810 

80 

101550.00 

95.29 

99.918  1 
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Table  45.  Selected  Throughput  Results  Sorted  By  Source  Packet  Payload  Length 


NO  RS 


TF  Len  (bytes) 

Throuahout  (Bps) 

SPLen  =  5  bytes 

41 

40531.69 

200 

50611.63 

400 

52225.88 

600 

52775.06 

800 

53058.13 

1000 

53220.63 

RS 


SP  Len  =  5  bytes 

41 

10497.56 

200 

29316.75 

400 

38129.13 

600 

42371.25 

800 

44863.38 

1000 

46494.06 

TF  Len  (bvtes) 

Throuaheut  (Bps) 

SP  Len  =  1 94  bytes 

TF  Len  (bvtes) 

Throuaheut  (Bos) 

41 

84816.80 

41 

22385.17 

200 

108028.90 

200 

62562.57 

400 

111457.90 

400 

81368.45 

600 

112631.60 

600 

90420.98 

800 

113237.80 

800 

95739.00 

1000 

113574.90 

1000 

99218.88 

TF  Len  (bvtes) 

Throuahout  (Bos) 

SP  Len  =  500  bytes 

TF  Len  (bvtes) 

Throuahout  (Bos) 

41 

85131.25 

41 

22787.50 

200 

109643.80 

200 

63693.75 

400 

113456.30 

400 

82850.00 

600 

114643.80 

600 

92075.00 

800 

115318.80 

800 

97481.25 

1000 

115593.80 

1000 

101025.00 

TF  Len  (bvtes) 

Throuahout  (Bds) 

SP  Len  =  2000  bytes 

TF  Len  (bvtes) 

Throuahout  (Bds) 

41 

87675.00 

41 

22750.00 

200 

109675.00 

200 

64000.00 

400 

113825.00 

400 

83350.00 

600 

115225.00 

600 

92700.00 

800 

115975.00 

800 

98250.00 

1000 

116425.00 

1000 

101800.00 

TF  Len  (bvtes) 

Throuahout  (Bos) 

SP  Len  =  20000  bytes 

TF  Len  (bvtes) 

Throuahout  (Bos) 

SP  Len  =  20000  bytes 

41 

86126.67 

41 

21646.67 

200 

108264.90 

200 

63046.36 

400 

111750.00 

400 

82000.00 

600 

113000.00 

600 

91250.00 

800 

113750.00 

800 

96500.00 

1000 

113750.00 

1000 

100500.00 

TF  Len  (bvtes) 

Throughput  (Bps)  |SP  Len  =  60000  bvtes 

41 

85876.67 

200 

104420.00 

400 

109668.90 

600 

110304.60 

800 

111178.80 

1000 

111576.20 

TF  Len  (bvtes) 

Throuahout  (Bos) 

SP  Len  =  60000  bytes 

41 

19661.11 

200 

60300.00 

400 

80105.96 

600 

89086.09 

800 

95682.12 

1000 

98781.46 
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Table  46.  Selected  Throughput  Results  Sorted  By  Transfer  Frame  Payload  Length 


No  RS 


RS 


SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  41  bytes 

5 

40531.69 

194 

84816.80 

500 

85131.25 

2000 

87675.00 

20000 

86126.67 

60000 

85876.67 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  41  bytes 

5 

10497.56 

194 

22385.17 

500 

22787.50 

2000 

22750.00 

20000 

21646.67 

60000 

19661.11 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  200  bytes 

5 

50611.63 

194 

108028.90 

1  500 

109643.80 

2000 

109675.00 

20000 

108264.90 

60000 

104420.00 

SP  Len  (bvtes) 

Throuqhput  (Bds) 

TF  Len  =  200  bytes 

5 

29316.75 

194 

62562.57 

500 

63693.75 

2000 

64000.00 

20000 

63046.36 

60000 

60300.00 

SP  Len  (bvtes) 

Throuqhput  (Bos) 

TF  Len  =  400  bytes 

5 

38129.13 

194 

81368.45 

500 

82850.00 

2000 

83350.00 

20000 

82000.00 

60000 

80105.96 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  400  bytes 

i  5 

52225.88 

194 

111457.90 

500 

113456.30 

!  2000 

113825.00 

!  20000 

111750.00 

60000 

109668.90 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  600  bytes 

5 

52775.06 

194 

112631.60 

500 

114643.80 

2000 

115225.00 

20000 

113000.00 

1  60000 

110304.60 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  600  bytes 

5 

42371 .25 

194 

90420.98 

500 

92075.00 

2000 

92700.00 

20000 

91250.00 

60000 

89086.09 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =800  bytes 

5 

44863.38 

194 

95739.00 

500 

97481.25 

2000 

98250.00 

20000 

96500.00 

60000 

95682.12 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  800  bytes 

!  5 

53058.13 

194 

113237.80 

1  500 

115318.80 

i  2000 

115975.00 

i  20000 

113750.00 

60000 

111178.80 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =  1 000  bytes 

5 

46494.06 

194 

99218.88 

500 

101025.00 

2000 

101800.00 

20000 

100500.00 

60000 

98781 .46 

SP  Len  (bvtes) 

Throuqhput  (Bps) 

TF  Len  =1000  bytes 

5 

53220.63 

194 

113574.90 

1  500 

115593.80 

2000 

116425.00 

20000 

113750.00 

60000 

111576.20 

162 


Table  47.  Selected  Data  Quality  Results  Sorted  By  Source  Packet  Payload  Length 


NO  RS _ RS 


TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  5  bytes 

41 

44.08 

200 

43.88 

400 

43.79 

600 

43.74 

800 

43.71 

1000 

43.68 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  5  bytes 

41 

45.23 

200 

43.77 

400 

43.47 

600 

43.36 

800 

43.31 

1000 

43.27 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  194  bytes 

41 

93.23 

200 

93.64 

400 

93.44 

600 

93.33 

800 

93.27 

1000 

93.20 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  1 94  bytes 

41 

91.75 

200 

93.42 

400 

92.77 

600 

92.53 

800 

92.43 

1000 

92.33 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  500  bytes 

41 

94.80 

200 

94.97 

400 

94.96 

600 

95.05 

800 

94.96 

1000 

94.90 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  500  bytes 

41 

91.64 

200 

94.18 

400 

94.19 

600 

94.19 

800 

94.12 

1000 

93.97 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  2000  bytes 

41 

94.59 

200 

95.31 

400 

95.42 

600 

95.54 

800 

95.57 

1000 

95.52 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  2000  bytes 

41 

91.33 

200 

93.98 

400 

94.34 

600 

94.43 

800 

94.50 

1000 

94.52 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  20000  bytes 

41 

89.99 

200 

93.85 

400 

93.98 

600 

94.07 

800 

93.92 

1000 

94.37 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  20000  bytes 

41 

89.72 

200 

92.70 

400 

92.55 

600 

92.62 

800 

92.67 

1000 

92.29 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  60000  bytes 

41 

81.73 

200 

89.73 

400 

91.72 

600 

91.73 

800 

93.04 

1000 

92.62 

TF  Len  (bytes) 

Data  Quality  (%)  SP  Len  =  60000  bytes 

41 

88.81 

200 

89.39 

400 

90.85 

600 

90.36 

800 

90.55 

1000 

90.52 
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Table  48.  Data  Quality  Results  Sorted  By  Transfer  Frame  Payload  Length  (Part  1  of  2) 


No  RS _ RS 


SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  41  bytes 

5 

45.23 

194 

91.75 

500 

91.64 

1000 

91.43 

2000 

91.33 

6000 

90.62 

20000 

89.72 

60000 

88.81 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  41  bytes 

5 

44.08 

194 

93.23 

500 

94.80 

1000 

94.80 

2000 

94.59 

6000 

93.44 

20000 

89.99 

60000 

81.73 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  200  bytes 

5 

43.77 

194 

93.42 

500 

94.18 

1000 

94.00 

2000 

93.98 

6000 

93.32 

20000 

92.70 

89.39 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  200  bytes 

5 

43.88 

194 

93.64 

500 

94.97 

1000 

95.33 

2000 

95.31 

6000 

94.97 

20000 

93.85 

89.73 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  400  bytes 

5 

43.47 

194 

92.77 

500 

94.19 

1000 

94.48 

2000 

94.34 

6000 

93.91 

20000 

92.55 

90.85 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  400  bytes 

5 

43.79 

194 

93.44 

500 

94.96 

1000 

95.43 

2000 

95.42 

6000 

95.11 

20000 

93.98 

60000 

91.72 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  600  bytes 

5 

43.36 

194 

92.53 

500 

94.19 

1000 

94.45 

2000 

94.43 

6000 

94.04 

20000 

92.62 

60000 

90.36 

SP  Len  (bytes) 

Data  Quality  (%)  TFLen  =  600  bytes 

5 

43.74 

194 

93.33 

500 

95.05 

1000 

95.44 

2000 

95.54 

6000 

95.21 

20000 

94.07 

60000 

91.73 
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Table  49.  Data  Quality  Results  Sorted  By  Transfer  Frame  Payload  Length  (Part  2  of  2) 


No  RS _ RS 


SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  800  bytes 

5 

43.31 

194 

92.43 

500 

94.12 

1000 

94.45 

2000 

94.50 

6000 

94.01 

20000 

92.67 

60000 

90.55 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  800  bytes 

5 

43.71 

194 

93.27 

500 

94.96 

1000 

95.43 

2000 

95.57 

6000 

95.40 

20000 

93.92 

60000 

93.04 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  1000  bytes 

5 

43.27 

194 

92.33 

500 

93.97 

1000 

94.40 

2000 

94.52 

6000 

94.04 

20000 

92.29 

60000 

90.52 

SP  Len  (bytes) 

Data  Quality  (%)  TF  Len  =  1000  bytes 

5 

43.68 

194 

93.20 

500 

94.90 

1000 

95.34 

2000 

95.52 

6000 

95.29 

20000 

94.37 

60000 

92.62 
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APPENDIX  J  -  Acronyms  &  Abbreviations 


AFIT  -  Air  Force  Institute  of  Technology 
ANOVA  -  Analysis  of  Variance 

ARTM  JPO  -  Advanced  Range  Telemetry,  Joint  Program  Office 

ATM  -  Asynchronous  Transfer  Mode 

BEP  -  Bit  Error  Probability 

BER  -  Bit  Error  Rate 

bps  -  Bits  Per  Second 

Bps  -  Bytes  Per  Second 

CCSDS  -  Consultative  Committee  for  Space  Data  Systems 

DoD  -  Department  of  Defense 

IRIG  -  Inter- Range  Instrumentation  Group 

GPS  -  Global  Positioning  System 

PCM  -  Pulse  Code  Modulation 

QoS  -  Quality  of  Service 

RCC  -  Range  Commander's  Council 

RF  -  Radio  Frequency 

RS  -  Reed- Solomon  encoding 

Sec  -  Seconds 

SP  -  Source  Packet 

TDMA  -  Time  Division  Multiple  Access 
TF  -  Transfer  Frame 
TM  -  Telemetry 
TPS  -  Test  Pilot  School 
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